Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Bug: Moving preview window around laggy, rendering issues (Linux) #1006
This seems to happen pretty consistently for me on Windows, regardless of UI scale or anything, and for every window (not just the preview window). The faster I move the mouse, the worse it happens.
It becomes less severe if I make the Aseprite window smaller, but CPU usage is still high while dragging. It occurs when I resize windows too, however it doesn't occur when I resize the palette or any other split-panel.
Sorry I can't be of more help. I'm on a recent master build.
Some info: I compiled version 1.1.3 of the release, the current master branch not compile on Windows, compile gives a lot of errors.
Changing the dpi 200-8200 has no effect. As I said the problem starts to occur when the mouse polling rate is greater than 250hz(reports / sec). My mouse can dynamicly change polling rate between 125-1000hz.
Lag higher with: screen scaling 100%, ui element scaling 200%. When i set 1000hz(modern mouse default) i have mouse freezes, very laggy, but 125Hz all good.
Moving preview windows laggy all time.
The rendering issues should be related to this commit 1588e83
When a widget is moved, its position (bounds) change, so paint messages in the queue are invalid and they're removed. It means that if we flood the message queue with mouse messages, paint messages aren't processed because they are invalidated by mouse messages. It was done to fix scrolling issues in the sprite editor/scrollable widgets (to blit/move/re-use still valid screen regions).
I'll see how to fix this issue, maybe window movement and splitters should flush drawing messages to update the screen as fast as possible.