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
arcooke opened this Issue Mar 9, 2016 · 18 comments

Comments

Projects
None yet
5 participants
@arcooke

arcooke 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 bug critical labels Mar 9, 2016

@dacap dacap added this to the v1.1 milestone Mar 9, 2016

@dacap dacap self-assigned this Mar 9, 2016

@dacap

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Mar 9, 2016

Member

😮 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.

😄

Member

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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Mar 9, 2016

Member

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

Member

dacap commented Mar 9, 2016

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

@allkhor

This comment has been minimized.

Show comment
Hide comment
@allkhor

allkhor 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.

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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 7, 2016

Member

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

Member

dacap commented Apr 7, 2016

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

@allkhor

This comment has been minimized.

Show comment
Hide comment
@allkhor

allkhor 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.

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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 7, 2016

Member

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)

Member

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

This comment has been minimized.

Show comment
Hide comment
@allkhor

allkhor Apr 7, 2016

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

allkhor commented Apr 7, 2016

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

@allkhor

This comment has been minimized.

Show comment
Hide comment
@allkhor

allkhor Apr 7, 2016

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

allkhor commented Apr 7, 2016

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

@geckojsc

This comment has been minimized.

Show comment
Hide comment
@geckojsc

geckojsc 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.

geckojsc 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

This comment has been minimized.

Show comment
Hide comment
@allkhor

allkhor 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.

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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 10, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 12, 2016

Member

@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)?

Member

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)?

@geckojsc

This comment has been minimized.

Show comment
Hide comment
@geckojsc

geckojsc 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 :)

geckojsc 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

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Apr 12, 2016

Member

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

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@HansLehnert

HansLehnert May 9, 2016

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

gif

HansLehnert commented May 9, 2016

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

gif

@dacap

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap May 9, 2016

Member

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.)

Member

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

This comment has been minimized.

Show comment
Hide comment
@HansLehnert

HansLehnert May 12, 2016

Yes, that fixed it. Thanks

HansLehnert commented May 12, 2016

Yes, that fixed it. Thanks

@dacap

This comment has been minimized.

Show comment
Hide comment
@dacap

dacap Jan 6, 2017

Member

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

Member

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

Discard enqueued kWinMoveMessage messages (fix #1006)
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