[x11] Reduce the MotionNotify events processing rate #145
Conversation
martincapello
force-pushed
the
reduce-motion-events-processing-rate
branch
from
f28d362 to
3e0bda3
Compare
martincapello
force-pushed
the
reduce-motion-events-processing-rate
branch
from
3e0bda3 to
f6d86f3
Compare
|
The only problem I find with this PR is that we are discarding a lot of mouse/stylus information to paint on the canvas. It might be a solution if we can enable this behavior when we are resizing something (a window, a selection, a slice, etc.) but not when we need all the motion events. |
|
Got the point. The only thing that makes me worry a bit is that Aseprite performance depends on the MotionNotify events rate. If the user has a fast enough hardware, Aseprite might not be able to process all the events on time to make it look smoother. So at the end, the hardware that generates the appropriate rate of events would be the best. |
|
Maybe we could modify this approach to at least limit the events rate... 🤔 |
2 participants
By reducing the processing rate of X11's MotionNotify events we remove a lot of pressure from the application, because it doesn't have to keep up with all the MotionNotify events generated any more.
Should fix aseprite/aseprite#5028. I say "should" because I was able to reproduce it just for the preferences dialog, so I'm not sure if it will fix the other cases reported by the users.