grafx2 lags when drawing with freehandtool

[GoogleCodeExporter]

What steps will reproduce the problem?

Drawing long lines with the freehandtool whitout releasing the key after a
while it lags, especially in zoomed view.

What is the expected output? What do you see instead?

the mousecursor schould follow the mouse without lag and on button release
it should stop drawing.

What version of GrafX2 are you using? On what operating system?

grafx2 from svn downloaded yesterday sry forgot the exact number (r117*),
under OpSys-Suse_9.0 but i expirenced the same problem with r1153 on
OpSys-openSuse_10.2.

Please provide any additional information below.

X11 6.9.0
libX11 1.3.2
SDL 1.2.14
don't know whats on the openSuse_10.2 PC is.

... greetings HoraK-FDF

Original issue reported on code.google.com by HoraK-...@web.de on 30 Nov 2009 at 6:06

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Jan 2010 at 7:39

• Added labels: Milestone-2.2

[GoogleCodeExporter]

I can't get that to happen with my Debian...
Putting on hold until there's a way to reproduce it.

Original comment by pulkoma...@gmail.com on 17 Jan 2010 at 8:11

• Added labels: Milestone-NotPlanned, OpSys-Linux
• Removed labels: Milestone-2.2, OpSys-

[GoogleCodeExporter]

Hi,

maybe it has something to do with the SDL for linux? Because with the Windows 
Version
on the same PC it runs without any lag.

... greetings HoraK-FDF

Original comment by HoraK-...@web.de on 18 Jan 2010 at 11:17

[GoogleCodeExporter]

I've had this issue for a very long time with most if not all grafx2 versions. 
I have
no problem with other drawing programs like mypaint, GIMP and inkscape etc.
So I tried to find out why the input lag occurs. I first found out that when 
drawing
with the freehand tool in grafx2 my cpu gets maxed out but not by grafx2 itself 
but Xorg.
So a ran some tests with oprofiler and saw that it was calls that goes to the 
pixman
lib that slows the drawing down to a crawl.
Now i suspect that pixman heavily uses 2d acceleration to do what it does and 
as i
use an ati card with fgrlx i know that the current 2d implementation is crap. So
perhaps the bottleneck is in the graphics driver? And if that is the case how 
does
the other drawing programs do it without having these issues?

I would be really thankful if anyone could confirm this.
pulkomandy do you have a ati card?  

Original comment by DarkDefe...@gmail.com on 18 Apr 2010 at 8:02

[GoogleCodeExporter]

No, I have an intel GMA.
Have you tried adjusting the various mouse settings in the .ini config file and 
the 
preferences window ? (mouse sensivity, merge movement). I have merge_movement 
set to 
100 on this computer and it seems to avoid the problem.

Original comment by pulkoma...@gmail.com on 18 Apr 2010 at 9:18

[GoogleCodeExporter]

Setting "merge_movement" to 100 solves the problem!
Thanks! :)

Original comment by DarkDefe...@gmail.com on 18 Apr 2010 at 3:32

[GoogleCodeExporter]

http://code.google.com/p/grafx2/wiki/FAQ#Q:_The_program_is_very_slow_and_the_mou
se_cursor_has_a_lag_of_se
The phenomenon is mostly visible when drawing on top right of screen. When not 
using
the magnifier, Grafx2 will redraw/refresh a rectangle that goes from your mouse
cursor (top right) to the mouse cursor coordinates in the status bar (bottom 
left).
The bigger this rectangle, the more work for the graphic system.
We cannot detect mouse update frequency, unfortunately. So you have to set
merge_mouse_movement yourself, for example by starting at 2, and increasing it 
by 1
until the lag is no longer a problem.

We have optimized grafx2 to ignore queued positions when they are not required, 
so
for example when moving the cursor around without drawing, it never lags. Maybe 
we
could reduce the problem even more by implementing a frame-skipping system... 
ie even
if 200 mouse positions are taken into account, no try to redraw the screen 200 
times,
for example with a LCD at 60Hz, only redraw if 1/60s has passed since last 
redraw.
This would also reduce the "CPU" cost, even on systems with no lag.

Original comment by yrizoud on 18 Apr 2010 at 3:38

[GoogleCodeExporter]

We could switch to multi_rectangle update method on linux, maybe ? I think it 
works 
better...

Original comment by pulkoma...@gmail.com on 18 Apr 2010 at 4:21

[GoogleCodeExporter]

Multi rectangle causes blinking of the mouse cursor (and brush), and I don't 
think I
can stand it anymore, after having smooth mouse/brush displacement for so many 
months :/

Original comment by yrizoud on 21 Apr 2010 at 3:45

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 9 Aug 2010 at 9:45

• Added labels: Component-Input

[GoogleCodeExporter]

I got such issue too, Linux only (OpenSuse 11.2 & 11.3, it doesn't matter, I 
think).
It appears only when zoom is enabled. Checked on PC 1core 3ghz + ATI Radeon 
9600 pro (both free and ATI drivers) and 2core 2ghz + Intel GMA X3100 (965 
xhipset) laptop. Same result with touchpad and few usb/ ps2 mouses.
Got no problems under Windows. It seems it's sth wrong with linux SDL lib usage.

Original comment by jackfros...@gmail.com on 30 Oct 2010 at 3:42

[GoogleCodeExporter]

Can you try revision 1644 or later ? (ask if you need a source archive) This 
change avoids a lot of work when an input device floods the SDL event queue.

Original comment by yrizoud on 5 Nov 2010 at 1:09

[GoogleCodeExporter]

Just updated to 2.3 under linux 64bit, 800dpi mouse here, so that could be the 
cause, I've already seen this problem but it seemed to be less problematic on 
previous versions.
I don't see particular spikes of cpu but the cursor lags pretty badly if I try 
to move the mouse quickly.

Original comment by 00.rgb.s...@gmail.com on 11 Apr 2011 at 6:13

[GoogleCodeExporter]

Info about DPI will not help, but it would be useful to know how many times per 
second  your mouse sends coordinates.
1) Try to grab a large brush (non-transparent 200x200), and move the mouse in 
rapid circles, especially in the top right angle of the window : Does any lag 
appear ?
2) Then try with a single dot brush, draw in circles quickly, especially in the 
top right angle of the window : Does any lag appear ?
If it's the second case, the setting "Merge movement" in Options/Input may 
help: set it to 100 and see if it changes anything. (If it fixes, set it to 1 
and increase by 1 until the issue disappears, it's a tradeoff between CPU usage 
and faithfully following each little mouse movement)

Original comment by yrizoud on 11 Apr 2011 at 6:34

[GoogleCodeExporter]

If setting Merge_movement>0 solved the issue, please try setting it back to 
zero and using r1780 from SVN or here: 
http://code.google.com/p/grafx2/downloads/detail?name=grafx2-2.3.1780-src.tgz
I made a change so that the status line has its own rectangular screen update, 
instead of using a huge rectangle that contains both the status line and the 
part where you're drawing. From what I've read, SDL graphics on X11 are very 
slow, so this change should avoid a lot of very time-consuming work : no more 
lag and reduced CPU usage.

Original comment by yrizoud on 16 Apr 2011 at 6:40

• Changed state: Accepted

[GoogleCodeExporter]

Works like a charm here! No more lag with merge movement 0 on the latest svn.
Thanks! :D

Original comment by DarkDefe...@gmail.com on 17 Apr 2011 at 9:26

[GoogleCodeExporter]

Original comment by yrizoud on 18 Apr 2011 at 10:57

• Changed state: Fixed