Mouse lag on Linux

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install Arch Linux AUR version 0.9.5
2. Start aseprite
3. Experience mouse lag when moving cursor around screen

What is the expected output? What do you see instead?
Expected native mouse speed without lag but instead the mouse had a huge amount 
of lag making it unusable.

What version of the product are you using? On what operating system?
Version 0.9.5 running on Arch linux using Linux 3.12 x86, xfce 4.8, Nvidia 
Geforce Proprietary drivers.

Please provide any additional information below.
Seems like a similar issue to 
https://code.google.com/p/aseprite/issues/detail?id=76 but I tried both 
changing the ScreenScale to 1 and starting a seperate x instance but neither 
helped remove the mouse lag.

I googled around for solution but only found the previous bug report and a 
report from another user of a similar lag experince on linux 
http://www.ludumdare.com/compo/category/ld-27/?author_name=meszka (mentioned in 
the 'Graphics tools' section)

Original issue reported on code.google.com by a.w.ma...@gmail.com on 17 Nov 2013 at 7:34

[GoogleCodeExporter]

Confirmed on Ubuntu 12.04 (VMWare).

It doesn't seem to be limited to just the mouse, the entire application is 
extremely laggy, making it impossible to do just about anything.

If I had to guess I'd say it was an allegro problem.  I seem to recall Allegro 
requiring a yield_timeslice() function to play nicely with windowing systems.  
Haven't used Allegro in years, but the function looks like it's still there in 
some form.

Looking in to this some more.

Original comment by DocHoncho@gmail.com on 22 Nov 2013 at 6:20

• Changed state: Started

[GoogleCodeExporter]

If you find a solution it would be great. The real solution is to change the 
way events are processed (i.e. changing Allegro 4 backend to Allegro 5 or SDL, 
which use messages queues).

You can start looking at: 
https://github.com/aseprite/aseprite/blob/dev/src/ui/message_loop.cpp

Original comment by davidcapello on 22 Nov 2013 at 10:23

[GoogleCodeExporter]

Confirmed on #! Waldorf (With Jessie repo's)

Original comment by jgsww...@gmail.com on 26 Nov 2013 at 1:01

[GoogleCodeExporter]

Maybe a temporal solution: 
https://code.google.com/p/aseprite/wiki/FAQ#Why_do_I_see_double-sized_pixels

Original comment by davidcapello on 18 Dec 2013 at 2:43

[GoogleCodeExporter]

As mentioned in the initial report I did try setting the ScreenScale to 1 and 
starting a separate dedicated X instance just for aseprite but neither helped 
with the lag.

Original comment by a.w.ma...@gmail.com on 18 Dec 2013 at 3:35

[GoogleCodeExporter]

I also have this problem on Arch Linux x86_64. The issue seems to me to be 
related with mouse acceleration. When I move the mouse slowly, the cursor is 
able to keep up. However, if I move the mouse at a higher speed, the on screen 
cursor is unable to keep up. There seems to be a certain threshold for what 
speed Aseprite is able to keep up with the mouse movement and when it falls 
behind. As was mentioned before, my guess would be that program can't keep up 
with the mouse events.

Original comment by trooper...@gmail.com on 31 Dec 2013 at 5:45

[GoogleCodeExporter]

I found a workaround which fixed the mouse lag for me: changing my mouse 
polling rate from 1000Hz to 500Hz.
Here is a general howto: 
https://wiki.archlinux.org/index.php/Mouse_Polling_Rate or if you're using a 
Razer mouse along with razercfg like me, you can set it there.
For completeness: I'm using aseprite 0.9.5 (from AUR) on Arch Linux x86_64.

Original comment by mesz...@gmail.com on 23 Apr 2014 at 6:49

[GoogleCodeExporter]

Original comment by davidcapello on 17 Jul 2014 at 3:30

• Added labels: OS-Linux

[GoogleCodeExporter]

I can confirm this bug. Arch linux 32 bit. Compiled from AUR. The application 
is unusable because of mouse lag.

Original comment by cosku....@gmail.com on 25 Jul 2014 at 6:24

[GoogleCodeExporter]

Also experiencing this on Arch using aseprite 1.0.2. It's really unusable.

Original comment by whatshis...@gmail.com on 12 Aug 2014 at 7:39

[GoogleCodeExporter]

This problem seems to be an issue with the mouses polling rate, if set too high 
it seems that aseprite cant keep up. For my Roccat Kone XTD I needed to tune my 
polling rate from 1000Hz to 500Hz which fixed the issue entirely.

Original comment by BRAX...@gmail.com on 22 Jul 2015 at 2:48

[GoogleCodeExporter]

Hi BRAXS69, the new issue tracker is here: 
https://github.com/aseprite/aseprite/issues/283

Original comment by davidcapello on 22 Jul 2015 at 12:53