After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 470869 - Slow performance while painting digitally
Slow performance while painting digitally
Status: RESOLVED INCOMPLETE
Product: GIMP
Classification: Other
Component: General
2.4.x
Other Windows
: Normal normal
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2007-08-27 22:21 UTC by Alexander Zubov
Modified: 2008-10-30 19:57 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexander Zubov 2007-08-27 22:21:09 UTC
I noticed that rc1 and previous development builds are very slow on Windows. Meaning when I use brush/airbrush tool with my Wacom tablet to do digital painting, I get delay between actual strokes and appearance of it on the screen. It is especially true for custom brushes and for big size brushes. Same thing true for smudge/dodge/burn tools.
I would never expect for Adobe Photoshop CS2 to be away faster than GIMP with the same brushes and parameters of an image, even though Photoshop is a "heavier" app.
It is really hard to paint with such performance.
Thank you.
Comment 1 Brin 2007-08-29 13:37:59 UTC
I'm seeing similar performance issues,
looks to be a regression from 2.2.17 to 2.4.0-rc1
I created a new image with the template 1600x1200 and then turn off the "background" layer visibility to display the checkerboard
2.2.17 redraws in under 1/2 second
2.4.0-rc1 redraws in around 1-2 seconds, you can see the tiles redrawing
Cheers
Brin
Comment 2 Liam Quin 2007-08-29 16:40:42 UTC
For what it's worth I'm also seeing this, with (for example) a relatively small 40-pixel-radius soft brush on a large image at 25% or 50%, gimp is now about 2 seconds behind my strokes for me.  Some of this can probably be accounted for by the time to make the undo thumbnail, but it's noticeably slower than a month ago.

Comment 3 Michael Schumacher 2007-08-29 16:50:29 UTC
Could be related to bug #322778. The rules and brush outline are mentioned to have a considerable impact.

Maybe this is a duplicate...
Comment 4 strata_ranger 2007-09-11 12:02:37 UTC
Probably.  Tablet lag on Windows systems is technically GTK-related, and has been reported several times.  I run GIMP 2.2.13 on an 800MHz machine; even on a pixel brush with the Pencil tool, the tablet always lags about 1/4 second behind the mouse cursor, while in other programs (Photoshop, Painter, etc.) the tablet tracking is spot on.
Comment 5 Brin 2007-09-11 12:16:03 UTC
Should I log a seperate bug for slowness when changing layer visibility on windows? As its un-related to using brushes or tablets.
Comment 6 Sven Neumann 2007-09-11 13:02:15 UTC
Not unless you can also provide useful profiling information.
Comment 7 Sven Neumann 2007-10-10 12:38:13 UTC
We need profiling information to be able to do anything about this. So if anyone wants to see this improved, please run GIMP in a profiler and report back when you can point out where the CPU time is spent.
Comment 8 Michael Schumacher 2008-07-21 12:30:40 UTC
Is this obsolete? The redrawing problems in early 2.4s are known and fixed, would be nice to know if these problems do still exist.
Comment 9 Michael Schumacher 2008-09-13 20:10:06 UTC
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!