Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Moving preview window around laggy, rendering issues (Linux) #1006

Closed
LuckySandwich opened this issue Mar 9, 2016 · 18 comments
Closed

Bug: Moving preview window around laggy, rendering issues (Linux) #1006

LuckySandwich opened this issue Mar 9, 2016 · 18 comments
Assignees
Milestone

Comments

@LuckySandwich
Copy link

@LuckySandwich LuckySandwich commented Mar 9, 2016

Best explained with a video: https://www.youtube.com/watch?v=kKWBo3wztq0

Not a major issue, but it puts a heavy load on the CPU. Feels like I'm winning a game of Solitaire every time I move the window, can't complain.

I'm using 1.1.3 on Linux Mint

@dacap dacap added this to the v1.1 milestone Mar 9, 2016
@dacap dacap self-assigned this Mar 9, 2016
@dacap
Copy link
Member

@dacap dacap commented Mar 9, 2016

😮 it happens on Windows too. I'll fix this ASAP

Feels like I'm winning a game of Solitaire every time I move the window, can't complain.

😄

@dacap
Copy link
Member

@dacap dacap commented Mar 9, 2016

Anyway it behaves randomly. Sometimes it happens and other times it doesn't happen.

@allkhor
Copy link

@allkhor allkhor commented Apr 7, 2016

Confirmed on Ubuntu 14.04 x64. Moving canvas very laggy too and makes high cpu usage. It's happened only if i used mouse, when used wacom pen Aseprite work correct.

@dacap
Copy link
Member

@dacap dacap commented Apr 7, 2016

Hi @allkhor, are you using the official release? or a compiled one?

@allkhor
Copy link

@allkhor allkhor commented Apr 7, 2016

Hello @dacap, im compile current master branch, CMAKE_BUILD_TYPE:STRING=Release, and upstream curl branch. Aseprite 1.1.2 work good.

@dacap
Copy link
Member

@dacap dacap commented Apr 7, 2016

Has your mouse high resolution? (I'm trying to understand why moving the canvas is slow with the mouse but not with the wacom pen)

@allkhor
Copy link

@allkhor allkhor commented Apr 7, 2016

I have logitech g600 (200 - 8200dpi) when i change dpi(hardware) no affect here.

@allkhor
Copy link

@allkhor allkhor commented Apr 7, 2016

Maybe it happens because mouse has 1000Hz polling rate and the wacom table has a lower polling rate?

@exelotl
Copy link

@exelotl exelotl commented Apr 9, 2016

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.

@allkhor
Copy link

@allkhor allkhor commented Apr 10, 2016

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.

@dacap
Copy link
Member

@dacap dacap commented Apr 10, 2016

The rendering issues should be related to this commit 1588e83
specifically these lines:
1588e83#diff-fa5a5001ac6008c80a38b2326237bfe8R624
and
1588e83#diff-fa5a5001ac6008c80a38b2326237bfe8R1467

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.

@dacap
Copy link
Member

@dacap dacap commented Apr 12, 2016

@geckojsc Could you please give a try to this issue on Windows with the new v1.1.4 release (the official one, which is compiled with Skia)?

@exelotl
Copy link

@exelotl exelotl commented Apr 12, 2016

@dacap yeah, it appears to be fixed now! Finally decided to buy on itch.io. Compared to Aseprite-old-backend.exe which was included in the installer, the CPU and memory usage of the new build are both generally improved. This also fixed #1051 for me :)

@dacap
Copy link
Member

@dacap dacap commented Apr 12, 2016

@geckojsc glad to hear that Jeremy! And thanks for your support 🍻

This issue should be fixed when the Skia port is ready for Linux.

@dacap dacap added the linux label May 6, 2016
@HansLehnert
Copy link

@HansLehnert HansLehnert commented May 9, 2016

Wanted to point out I'm getting this issue on Windows 10 running current master branch compilation.

gif

@dacap
Copy link
Member

@dacap dacap commented May 9, 2016

Hi @HansLehnert, could you give a try to the Skia back-end? It should fix the issue. (See instructions INSTALL.md about how to compile Aseprite with the Skia back-end.)

@HansLehnert
Copy link

@HansLehnert HansLehnert commented May 12, 2016

Yes, that fixed it. Thanks

@dacap
Copy link
Member

@dacap dacap commented Jan 6, 2017

eb0f046 has fixed some UI problems, and also reduced this issue a little, anyway still visible on Alleg/Linux port

@dacap dacap modified the milestones: v1.1, v1.1-bugs Jan 8, 2017
@dacap dacap removed this from the v1.1 milestone Jan 8, 2017
@dacap dacap modified the milestones: v1.1-bugs, v1.2-bugs Sep 12, 2017
@dacap dacap modified the milestones: v1.x-bugs, v1.2 Aug 16, 2018
@dacap dacap closed this in b5ace78 Aug 16, 2018
dacap added a commit that referenced this issue Aug 17, 2018
When we're moving or resizing a window, sending several
kWinMoveMessage doesn't make sense. So we discard all kWinMoveMessage
and re-enqueue a new one with the latest window bounds.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.