GNOME Bugzilla – Bug 304798
Painting brush outline is slow
Last modified: 2012-05-07 04:39:39 UTC
A brush with a complicated outline (for instance a 300x300 brush made from acrylic paint strokes) seems to be slow to move about on the screen. The problem is solved by unmarking the checkbox 'Show brush outline' in Preferences / Image Windows / under 'Mouse Cursors'. If the brush has a simple outline then the problem doesn't seem to occur even though is is big. Other information: I use: o) Ubuntu Hoary (debian based) o) Nvidia MX440 graphics card o) Xorg, native drivers, not Nvidia's own proprietory drivers (e.g. there is no OpenGL available)
GIMP does not make use of OpenGL or any other fancy graphics-card functionality; it is a pure 2D application. Basically you are just asking GIMP to work really really hard, and it can't keep up -- there's probably no simple change that will help much. (If you would like to build a profiling-enabled version of GIMP and do some detailed testing, though, feel free.) So this is really not a bug, just a limitation, and I am going to resolve it as NOTABUG. You didn't mention the speed of your processor, by the way -- this is probably the single most important factor. Also, as a rule, you should try to upgrade to the latest stable version before reporting a bug. In this case it almost certainly won't make a difference, but it is still a good rule.
I had explicitely asked the bug reporter to open this report. Closing it without a good reason is not very nice. Reopening so that we remember to profile this part. I am confident that the GIMP code involved here can be optimized.
This might be the same problem that is causing bug #149616. The same code is being used here, to find the boundary and to draw it.
This change might have had a noticable impact on this problem: 2005-06-26 Tor Lillqvist <tml@novell.com> * app/tools/gimppainttool.c (gimp_paint_tool_draw): Store the GimpBrushCore::brush_bound_segs as sorted (the result of sort_boundary), as the only place where it is used (gimp_draw_tool_draw_boundary()) would sort it each time it is called anyway. * app/tools/gimpdrawtool.c (gimp_draw_tool_draw_boundary): Correspondingly we now don't have to sort the boundary here.
What do we do about this now? Has anything changed, can we close this bug?
*poke*
resolving as INCOMPLETE due to lack of response to NEEDINFO from the bug reporter for well over a year.
.. Failed to respond to life in general in that time period.. Yesterday an empty mail ticked into my box about this bug, so I'd just as well start on this again: Example of brush with an outline that is updated slowly (could not figure out how to attach it): http://vaults.atomicmonstergirls.net/public/cornucopia/program-gimp/brushes/Pastel-010.gih Systems: PC + Windows, Ubuntu, Archlinux, Debian (all I've tried) CPU: AMD XP 2500. Intel Centrino 1700mhz. Graphics: nvidia 6600gt, 6200go Gimp: 2.2, 2.4 (my ArchLinux currently has 2.4.3) Try the brush, you'll know what I mean. I haven't looked in the code, but I will assume you do not render an outline edge-list more than once.. Hopefully you simply have a pixel buffer with the rendered brush outline that you mask onto the existing graphics buffer on every mouse event? It cannot possibly be as slow as observed. Kind regards - Rene Jensen P.S. If I just disable outline rendering in the preferences, I do not really have a problem. In fact, I think it is hard to see what is going on during a paint operation with a visible outline anyway.
Your assumption is wrong. Since the rendering of the brush outline needs to be done using XOR, it is left to GDK to do that. Your brush has a very complex outline, so this can become rather slow. What should be done is to simplify the outline.
Created attachment 103021 [details] [review] patch that adds a call to boundary_simplify() This patch introduces a call to boundary_simplify(). But it turns out that this function doesn't work good enough.
I've committed this to both branches: 2008-01-22 Sven Neumann <sven@gimp.org> * app/paint/gimpbrushcore.c (gimp_brush_core_create_bound_segs): dilate the brush mask in order to obtain a simpler boundary. Addresses bug #304798. Let's keep this open until we get some feedback.
2008-01-22 Sven Neumann <sven@gimp.org> * app/paint/gimpbrushcore.c (gimp_brush_core_create_bound_segs): smooth the mask instead of dilating.
Could it be that the above change horked the outline of (at least) the 1x1 pixel brush in 2.4.4 on Windows? If you use the 1x1 brush (or a custom brush made with the brush editor with a radius of even 0.2) you'll get a 3x3 square outline instead of the 1x1 square it previously was (and, really, ought to be) - that makes using the pencil tool to edit single pixels at 800% zoom rather tedious. Maybe it should only smooth the brush if it is bigger than a certain size (8x8? 16x16?), as I wouldn't think this does improve performance much for such small brushes...
Yes, this change could probably need some further fine-tuning...
This change improves the hack, but it still has issues: 2008-02-04 Sven Neumann <sven@gimp.org> * app/paint/gimpbrushcore.c (gimp_brush_core_create_bound_segs): only smooth the inner area of the mask so that we don't enlarge the boundary for hard brushes (bug #304798).
I found that it makes most sense to only apply the workaround for large brushes: 2008-02-04 Sven Neumann <sven@gimp.org> Merged from trunk: * app/paint/gimpbrushcore.c (gimp_brush_core_create_bound_segs): changed workaround to look at the brush size instead (bug #514309).
This still occurs in Windows Gimp 2.6.5 pentium d 2.8GHz only by disabling brush outline does the behavior disappear, but you do not know what your brush looks like as you work nor do you know where the boundaries are.
Perhaps we can do as mypaint (http://mypaint.intilinux.com) does, just only for complex brushes (based on the number of vertices in the outline)... just show a circle of approximately the right size (with a marker in the center, perhaps like an asterisk shape, to show that this is an approximation.) \|/ -+- /|\ when a stroke is actually ongoing (and only show the detailed outline when the user is simply moving about without drawing) IMO an detailed stroke outline isn't very usable during drawing a stroke anyway, and my personal experience is that this part of the slowdown is the worst in terms of usability -- Moving about too slowly is annoying, but stroking too slowly has far more potential to damage workflow.
*** Bug 592016 has been marked as a duplicate of this bug. ***
Someone should check if this is still a problem in the master branch where we don't use XOR drawing any longer.
I'm sorry, but I simply can't get GIMP to paint an outline with the version in git. I assume it is still only a matter of checking "Show brush outline" in Preferences->Image Windows->Mouse Pointers. I made a 'git clone' of babl, gegl, gimp today (2010-jan-28 - pardon me, but I don't know git well enough to get the revision number out of it) on a clean Ubuntu 10.04 (on a virtual machine). Painted with the paint brush and air brush. None of them rendered an outline of neither my own brushes nor any other, large nor small.
*** Bug 631766 has been marked as a duplicate of this bug. ***
It's in fact even worse with cairo, so I'm hijacking this bug to track the "new" slowness. Setting milestone to 2.8 because we really should do something about it.
Cairo painting got considerable performance boost little while ago and now performs better than XOR drawing ever did. There are ways to improve it further, but it is no longer blocking 2.8 release.
I just got the update to 2.8 in archlinux and still using brushes when the outline is enabled feels horribly slow and jerky. Are there any known issues left?