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 119423 - speed regression when painting (esp. with airbrush)
speed regression when painting (esp. with airbrush)
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
git master
Other Linux
: High major
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2003-08-08 11:00 UTC by Jakub Steiner
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jakub Steiner 2003-08-08 11:00:10 UTC
Painting got a lot slower in 1.3 compared to 1.2. To expose a dramatic
slowdown, use the airbrush tool. Make a 100px brush with 0 hardness
(fuzzy). Scribble quicky on a 600x600px image. The repaints are fine in 1.2
but unusably slow in 1.3.
Comment 1 Jakub Steiner 2003-08-08 11:01:39 UTC
It's a regression, marking as 2.0 milestone
Comment 2 Jakub Steiner 2003-08-08 11:02:20 UTC
it's even more dramatic on a layer with alpha.
Comment 3 Jakub Steiner 2003-08-25 21:16:17 UTC
Just a little Multimedia demonstration ;)

http://jimmac.musichall.cz/stuff/pathetic-brush.avi

info:
4000x3000 px RGB image (no alpha channel)
paintbrush with a 200px fuzzy brush
the system is a pIII/700 with 512MB RAM, 400 tile cache in gimp.
Comment 4 Dave Neary 2003-09-11 07:29:33 UTC
It would be nice to test against older versions (start with 1.3.8 say,
and work backwards to find the regression) -I don't think it could
have been introduced between 1.2.0 and 1.3.0 (at least I hope not,
because there was a *big* change there), since the paint core mostly
got changed after that (around 1.3.5/6).

It would be nice to go back to the old builds and see when it broke.
One thing, though - would old 1.3.x releases build clean with gtk+
2.2.x? Well, there's one way to find out :)

Dave.
Comment 5 Sven Neumann 2003-09-11 11:31:19 UTC
IMO going back to the old builds is a complete waste of time. What
needs to be done is profiling. We will have to do some profiling
anyway, so instead of building old versions, why not build the latest
one with -pg instead and check where we are spending our time.
Comment 6 Sven Neumann 2003-10-08 13:40:43 UTC
The problem is that I cannot reproduce the slowdown. I've tested the
example that Jimmac showed off in his movie. When I compare 1.2 and
1.3 the new GIMP even feels a bit faster, definitely not noticeably
slower.

I started to look at this problem using valgrind/cachegrind. I've also
added some debug output to gimppaintcore.c to verify that the brush
mask cache is working. All is looking well.
Comment 7 Michael Natterer 2003-10-08 14:50:43 UTC
Fixed in CVS:

2003-10-08  Michael Natterer  <mitch@gimp.org>

	Fixed bug #119423. There was no speed regression with the actual
	painting, just with the display update (which effectively led to
	faster painting, it just felt slower).

	* app/display/gimpdisplayshell.c (gimp_display_shell_flush): added
	"gboolean now" parameter and update the display immediately if
	it is TRUE.

	* app/display/gimpdisplay.c (gimp_display_flush_whenever): pass
	the "now" we got passed to the function above, so calling
	gimp_display_flush_now() really flushes *now* again.