Last summer I noticed two behaviors in paint strokes that I believed were incorrect.

1. "airbrush" strokes painted on both timer and mouse events, so a slow airbrush could be "sped up" by moving the mouse.

Although it may be somewhat intuitive to have a the rate of the airbrush speed up if you "shake" the airbrush, I think that this is an unintended feature. If we want to add a "airbrush rate goes up if mouse moves" feature, I think it should be done deliberately.

2. "smooth stroke" would set its initial mouse position based on the first successful "hit" on the pbvh raycast instead of the first place the mouse is pressed.

This means that you could not properly start a smooth stroke that does not start out hitting the object surface, however paint strokes are purely 2D operations and should not depend on anything being hit in 3D, so the 2D stroke should be smooth and when the smoothed point finally arrives over the object's surface the stroke should start.

The modification of "test_start" to take the smoothed mouse coordinate also sets us up to be able to handle snapped coordinates later

--

I removed the "paint_stroke_space_enabled" external function because it clashed with the internal "is_space_enabled". The only use for this function was an XXX issue that needs to be addressed separately.

Another fix is to force drawing for every event, you can also see where the smooth cursor is while the mouse is not over the object. Before there was a general problem where the cursor would not be updated unless you caused a change that resulted in a need to redraw the object.

Finally, although last_mouse_position is not used by the sculpt_update_step function, it was being incorrectly updated to be the same as the current mouse position. This would have been a problem if something in sculpt actually used it. However, it looks like sculpt just duplicates some of the work of saving the last mouse coordinate.

As with the other Onion patches, this one anticipates some future changes. The "one_time_init" function and the "stroke predicates" as well as the "input_ok" variable are all artifacts from the future that were convenient to go ahead an integrate.