Awesome! I think this issue is also present with texture painting. That is with input devices with high polling rate (like 1000Hz mice), some operations are executed way to often and causes blender to slow down to a crawl.

I don't know if setting a timer would be the best solution though. Perhaps we could have a distance threshold instead? I don't really know what would be best to be honest.

Thanks!
I have compiled and tested on Linux.

This patch makes working in Linux more comfortable when the brush is not relatively big (or view very zoom out) with this problem in Linux:
https://developer.blender.org/T54807

But when the brush is very big, in Linux the lag in response is still very large, for example in this file:
https://developer.blender.org/T62718#645732

So I guess that problem in Linux is not entirely related to this.

For a simple grab operation, we can update once per redraw. Transform operators work the same way. That is done by ignoring any INBETWEEN_MOUSEMOVE events, and only using MOUSEMOVE.

There may be other tools with issues like this, and I don't know off the top of my head how dynamic topology interacts with this. In general for something that draws a curve I'd expect the number of updates to be defined by distance and spacing. For airbrush-like behavior it makes sense to use a timer. In both cases it is possible in principle to keep the UI more responsive by letting the updates lag behind, and only doing updates for N milliseconds at a time before redrawing.

But the basic grab case does not need timers or distance as far as I know.

@Brecht Van Lommel (brecht) @Sebastian Parborg (zeddb) I'm testing it ignoring INBETWEEN_MOUSEMOVE events and it works perfectly. Dyntopo also works fine. How should we approach this? Should I just add specific code for the grab brush here until we find a more general solution?

could this type of interaction improve the situation with edit mode performance or is it a whole other system and therefore unrelated?

@Pablo Dobarro (pablodp606), I think this is the general solution, some tools just don't need all the inbetween mouse events. The paint stroke code has more checks for specific tools like paint_tool_require_location, we can do the same here. The implementation of these things could be improved with a bigger refactor, but it's not that much of a problem.

I guess add something like paint_tool_require_inbetween_mouse_events(). Rotate and Thumb tools need this as well.

@noki paike (amonpaike), this is unrelated to edit mode performance.

The latest version of the patch is almost solving the problem related to Grab brush that I showed in my previous message!
My question is whether this really solves that bug for Linux if this could be implemented for other brushes, or this helps in performance for Grab brush but the problem about Windows being faster than Linux still persists.