GNOME Bugzilla – Bug 471344
Circular brush strokes are not smooth and have corners
Last modified: 2009-08-03 20:56:00 UTC
I am posting a link to the image explaining what I mean. I noticed it through all development versions of GIMP 2.3.x, but I didn't have time to report it. http://img377.imageshack.us/img377/8476/gimpbrushstrokesqi4.jpg Window with smooth circular doodlings is from Photoshop.
Duplicate of bug #322778?
Not sure, since it doesn't seem to be tablet related. However, I remember an enhancement request about a better (smoother) interpolation of the mouse coordinates provided. Maybe the results get a little better for you if you enable perfect pointer tracking in the preferences, but then - maybe not. (Does this still exist? For some reason I am unable to spot it in the preferences. Or has this become a gimprc-only configuration?) This definitely is an enhancement request (and likely a duplicate), marking as such.
Kind of related, but not the same thing: bug #55366. I'll accept this as new bug for now.
Have a look at other bugs by Alexander. I'm pretty sure that a tablet can be involved.
I couldn't find bug #322778. If tablet would have anything to do with it, I would have same issues in other apps., but it seems like interpolation/smoothing lacking in GIMP. I don't have that problem with Photoshop and Painter.
Hm? Did you read bug #322778 at all? The behaviour of the tablet in other apps is not relevant here.
I just read it. Indeed it happens only when I paint fast. But is there a way to resolve the problem withing GIMP ? Or is it GTK+ bug?
Btw, I just tried to draw with mouse and I get the same results - corners.
Looking at the stroke interpolation code (gimpbrushcore.c:395), it strikes me that the problem is: * We want to interpolate along the line B->C, the segment that the pointing device just traversed. * but, meaningful smoothing cannot be performed unless the preceding point (A) and following point (D) are known. * There is a separate issue, that on Windows events are not received frequently enough to make a smooth curve. This is however a GTK+ issue rather than a GIMP one; GIMP can only partly ameliorate it by implementing stroke smoothing. Comments: * Preceding point (A) can be known with a few changes to the code; following point (D) is undefined if the stroke is the latest one. * Preceding point (A) is undefined at the starting stroke, it must be guessed. A smoothing variable S can be used in this way: A = B + (radius = S * dist (B,C), angle = angle_between (B,C) * S); That is, A is extrapolated by polar offsetting from B, proportional to S. S should normally be on the range [0..1.0] (but it might be useful to allow up to 4.0 for more flourished stroke beginnings) * Therefore, it seems to me that any smoothing algorithym needs a way to memorize, erase, and redraw the last stroke, as the following point D becomes defined. Until D is defined, use the formula defined above for extrapolating A. When D is defined, re-interpolate and redraw the stroke segment. For example: -User draws point 0; a dab is drawn. -User continues drawing (point 1); Points A and D are guessed, stroke from point 0..point 1 is drawn -User continues drawing (point 2); Point D is now known for segment between point 0 and point 1. Stroke from point 0..point 1 is redrawn, stroke from point 1 to point 2 is drawn (D is guessed, A is known (A == point 0)) -User continues drawing (point 3);Point D is now known for segment between point 1 and point 2. Stroke from point 1..point 2 is redrawn, stroke from point 2 to point 3 is drawn (D is guessed, A is known (A == point 1)) -and so on... * For the actual interpolation, Catmull-Rom is an appropriate algorithym to use (predictable, aesthetic, guaranteed to pass exactly over all input points). I have a straightforward Python implementation of it for reference. * I have high hopes of GEGL making the stroke draw/redraw feature that's required easy to implement. When that's available, I want to implement this stroke smoothing I've described. * Stroke cleaning (cutting out spurious points) is a independent issue, that IMO should be considered after smooth stroke interpolation is implemented. * Lastly, I assume that someone trying to draw sharp, angular lines would do so deliberately enough that the stroke interpolation would leave their angularity uneffected (ie. the interpolation routines would receive points that were themselves 'steps' along a straight line, and thus the interpolation would look linear as it should at that point).
Not sure if it makes sense to keep this bug report open. It's a well known and long-standing issue that we do linear interpolation between the mouse coordinates received during painting. This seems to be less of a problem on the UNIX platform, probably because the X server does a much better job at delivering mouse events than the Windows system does.
(In reply to comment #10) > probably because the X server does a much better job at > delivering mouse events than the Windows system does. Bug #322778 points in this direction.
(In reply to comment #10) > Not sure if it makes sense to keep this bug report open. I think it definitely makes sense to keep this report open since I think this is a completely reasonable enhancement request.
Bug #508639 is supposed to have some effect on this. But the problem is probably still there, perhaps less worse than before...
*** Bug 539923 has been marked as a duplicate of this bug. ***
it is not a windows problem: I can reproduce it under X (sidux) it is not a tablet problem: I can reproduce this with a mouse
it is not a gtk bug, because inkscape works properly. I think it is a mouse tracking problem: if mouse moving is fast, the program connects A and F, but without B, C, D, E points.
Andras -- can you test with 2.5.x (or better yet, SVN HEAD), and post whether the problem is fixed? stroke interpolation has been significantly improved since 2.5, courtesy of Alexia Death -- and performance may have been increased. For me, if I move very fast, I can still spot this problem at near-100% zoom levels. Higher zoom levels are always smooth. However, something that nobody seems to be accounting for here is that the mouse hardware only updates at a preset number of Hz. Thus, depending on your mouse hardware, it could be the mouse that is only noticing A and F points. Some mice allow you to adjust update rate; most mice do not. Inkscape could be doing a better job of interpolating than GIMP. It will take some careful research to work out whether the mouse, GIMP, or both are truly responsible for this problem.
In general, I am using windows and I have no experience in using and compiling testing versions, sorry. BTW, I can set my mouse property on the control panel of windows and it is set to 100 updates/second. If I set it to 200, there is perceptible change, a little bit smoother if any.
None of my code directly touches the interpolation code so the bug will still be there, tho may be a little less noticeable. This and size dependent stamp spacing are two issues that require reworking of the interpolation in paint core.
Created attachment 117648 [details] [review] Patch to implement two-tier interpolation in brush core and use catmull-rom for the top tier This patch introduces crude interpolation before letting linear do it neat magic. the crude interpolation is implemented as catmull-rom spline and as such needs acces to 4 points, the ones interpolated in between and one from before and one after. Predicting the after point gave very limited result, however, delaying the painting by one event when moving fast is of no issue. Related to this patch what it needs IMHO to be usable is timeout for the one event delay, so when the user stops the stroke instantly catches up and delay off when the stroke ends. In my mind this is a viable approach to paint tool interpolation with current paint core.
With tablet this produces gorgeous lines :D With mouse, there are often strange bumps in an otherwise well smoothed line (which happen even with zoom>500%). Try the following to demonstrate them, they are really strange and noticable in this example: 1. select 1 pixel brush (NOT circle 1 -- it is not 1x1! copy a single pixel and use clipboard brush if you must) 2. hold the mouse button down and move up at a 35 degree angle S L O W L Y 3. the mouse slides left in a nearly straight line, then appears to slide around the corner and suddenly becomes vertical. the overall effect looks like | | \ | | \________ \ \ I'm not sure if your timeout idea addresses the problem occurring here.. what I think needs to happen is that the strength of curve interpolation is reduced as the movement speed slows down. The patch appears to implement some kind of threshold like this, but if so, it is malfunctioning. And, holding shift while drawing is completely broken. Shift-clicking works, only. I suppose this is also due to the delay. In any case, shift-dragging should really have the same effect as dragging normally; since the stroke is interpolated anyway, it's really not meaningful.
Than you for testing! The change is not used when you move slowly. By your description what you see is most likely the result of uneven surface you move on. You should get the same result without the patch as well. I would appreciate it if you could test. This patch does not do smooth, it simply fills in the places where input device is not fast enough smoother. About shift dragging, I tried with unpatched SVN and it does what I expected it to do - nohting. It used to draw while shift and LBM were both pressed but that has been fixed for some time, because it caused issues when making polygons with tablets. Slips caused messes at turning points.
I have finally tested the patch with a tablet(dint have it available over the weekend), and MAN, it looks good. I wish somebody would advise me how this SHOULD be implemented so we could get it in SVN as soon as possible...
No, my mouse is clean and works well; I use it regularly in GIMP and it never exhibited this kind of lumpy movement until I tried your patch. What I was suggesting just meant that the slower the device moved, the closer the interpolation should come to linear interpolation. Obviously your code is not supposed to operate at all when there are enough events, but I think it is anyway. You can see how extreme the effect can be here: http://img.photobucket.com/albums/v449/neota/tech/stroke-lumpiness.png As an additional data point: I don't need to be drawing for this to happen. It can happen eg: when holding down 'Shift' and moving around to see the angle of the line that might get drawn. I just tested, and indeed that lumpiness only shows up with your patch -- the worst lumpinesses otherwise amount to deviations of <2 pixels from the ideal line, whereas they can become ~100 pixels off with your patch and a mouse. I just double-checked that I cannot get lumpy results with my tablet, and indeed I can't, no matter how slow I go, with or without your patch.
This is interesting. I don't seem to be able to replicate it. I specifically even found myself a mouse to test. Nothing. There is a commented out printf in the patch. Could you try commenting it in and seeing if anything is printed out while you do this and see the error? If it is then I would like to see the output. Also, abut the lumps. Does your whole mouse pointer move or only the drawn line deviates? None of the interpolation code should even be called when you are not actually drawing, so it is a mystery how it can influence hovering with shift down. Just to make sure, you are using a clean tree and right patch? Your slow deviations look like the errors from early agressive low level event smooth that have been fixed for ages in SVN.
The mouse pointer deviates too, yes. To clarify -- you don't even need to be holding shift down. That's just a way to see the effect easier. In fact, the lumps occur even when moving so slow that no debug messages are printed (ie the new code is not called). However, I'm unable to reproduce the larger lumps when the debugging messages are activated. 'svn status' thinks I have a clean tree (aside from your patch :) The only non-? output lines are these: M app/paint/gimpbrushcore.c M app/paint/gimpbrushcore.h M po-plug-ins/eo.po M po/eo.po M po/fr.po M po/lt.po M po/oc.po (I'm working on the esperanto translation; otherwise, fr,lt,and oc periodically cause problems and I have to adjust some silly thing in them to allow building to finish. Possibly a fix Sven made recently will eliminate that.) In fact, your patch was applied to svn-fresh files -- I deleted my existing files and used 'svn up' to restore them, just to be sure.
If your whole pointer deviates then the issue is in the way events come into X and long before any of my code sees it... How my code affects that is a mystery however. May be its a load issue that somehow triggers a glitch somewhere? Can you see a noticeable load difference between when running patched and unpatched GIMP, specially when the lumps occur?
I would also love to see if somebody else can test this for the repeatability of the above issue.
*** Bug 554627 has been marked as a duplicate of this bug. ***
I would like to add the remark that this bug is still alive, in 2.6 as I reported in bug 554627.
And I would like to remark that as you can see from above the bug is being worked on as evidenced per comment timestamps.
Created attachment 119935 [details] [review] Create core/gimpcoords-intrepolation.[ch] for bezier interpolation Separates coordinates interpolation of bezier curves to its own file. This file will also contain most of other kinds(ie catmul-rom) of interpolation done on gimpcoords once the work on this is done.
Created attachment 120136 [details] [review] Update to interpolation separation Cleanups as suggested by mitch
Created attachment 120837 [details] [review] Update 2 to interpolation separation
Created attachment 122358 [details] [review] First version of catmul-rom spliens based event filler Solves both this bug and the bug about spacing not adapting to size. Known issue is the use of arrays for queue. With highly inaccurate devices and large brushes when the queue gets long the performance penalty is severe, so moving to use of an actual queue container is planned. However now its time to give functionality and code structure feedback.
Created attachment 122359 [details] Sample of the output Please not that the sloppiness at high zoomouts with touchpad is mostly caused by the small size of the touchpad... I dint actually get to move my finger much to do 12%
Functionality is excellent! How spot-on the spacing scaling is, is especially noticable. 'Large brushes' is >= 46x46px, on this 1.2ghz machine.
Is that size limit when it becomes unusably slow? My usual test image is 1200x1600@50% zoom. I would love to have some commentary from a slower machine on where that limit is and how it changes with brush size and zoom for both tablet and mouse. About the use of queue structure, it turned out that actually it performed a lot worse because of needing constantly allocate memory for elements. Ive worked around the array reindexing so that is no longer done. The result is only slightly slower than using a tablet in 2.6 for all devices. There seems to be some serious overhead in processing many events vs processing one big jump even tho number of stamps to be painted is comparable. I need to take a look if I can figure out why that is. It was suggested in IRC that it might be caused by per event tile locking.
That size limit is when the brush strokes start to lag noticably behind the mouse movements as I move fast @ 100%. Using a large image (2048x1266) only slows things down a little. @ 50% zoom, even using a 3x3 brush can be noticably laggy, the lag starts to get bad @ 13x13 (6 radius). @ 33% zoom, any brush is very noticably laggy @ 125%, 100x10px brushes start to lag somewhat (this is similar to the performance before your patch)
David, what version did you patch? SVN? It seems a lot of the slowdown I am seeing is not caused by any of my changes but something that has happened in projection code. And GEGL projectiosn is totally busted. I cant even keep up with the 1.0px brush... I am myself going to try to patch 2.6 with this later tonight to make sure I know how much this really impacts and how much is it caused by the broken projection.
Created attachment 122786 [details] [review] Complete and cleaned version of event fill patch Please test and comment, and if all is well, commit. Should perform MUCH better than previous version. Difference with 2.6 side by side was minimal.
I was applying the patch to SVN HEAD, yes. New patch is pretty good for zoom <= 100%. When as zoom becomes greater than 100%, drawing is increasingly sluggish. I don't know if this is a regression; it is odd.
Indeed... I investigating what is going on.
Created attachment 125375 [details] [review] Updated event fill 2 minor changes. First, don't add timeout before done processing the last events and second, just relax fill density. Now, one event is filled for every 5px image space. Performance was considerably improved for me. However, Id appreciate performance testing on different hardware than mine...
With tablet, everything is much improved (no noticable lag at any zoom level). With mouse, behaviour for zoom > 300% is noticably improved (no noticable lag) and zooms <= 300% become increasingly lagged (with noticable lag already @ 300%)
Created attachment 125578 [details] [review] Updated event fill 2 This should mostly remove the performance difference between tablets and mice. David, performance testing would be much appreciated.
Works great! I have to zoom out to 12.5% to get any appreciable lag with mouse, and to get that much lag i have to scribble quite fast. I don't even know what the speed was before @ 12.5% since I normally avoid drawing at zoom < 100% anyway :) There is just one issue remaining.. when zoom >= 3200%, slowdown begins. When zoom == 10000%, it's very sluggish. at 25600%, it's laughably slow (~1sec to catch up with a single pixel brush being painted once) IMO at zoom >= 3200%, smoothing can reasonably be disabled entirely, as it will have very little effect. With such an automatic cut-out threshold, I believe this would be ready for committing to SVN.
Hmmm... I will check but the fill should not be invoked if traveled distance in in image space is no bigger than 4 pixels and at those zooms it certainly is not. The fill has no effect at all, because input provides much better resolution than the image already.
I've ran my tests. I did not notice any slowdown on any zoom-in(tried many levels from 800 to 25600) and fill is not invoked. Whatever happens in zoom-in is not due to this patch, at least not directly... It can be some combination bug manifesting for your setup... If you look in the patch/gimpdisplayshell-coords.c theres a define for EVENT_FILL_PRECISION, thats the value thats used to cut off fill. fill is done so that theres an event for half this distance. currently it is set at 8. I'm interested of your performance if you start taking it down. going below 3(1 event per 1.5 pixels) is pointless, but Id like to know where the performance starts to bite for you, if you take it down...
Created attachment 125597 [details] [review] Updated event fill 3 some code cleanup and higher fill ratio.
"currently it is set at 8" do you mean it was set to 8? the patch sets it to 6. With precision = 6 : lag when zoom == 25600% With precision = 5 : lag when zoom >= 12800% (except for the normal lag at <= 12%, which is almost certainly caused by the display-pyramid code) With precision = 4 : noticable lag when zoom >= 8800% With precision = 3 : noticable lag when zoom >= 7800% With precision = 2 : noticable lag when zoom >= 7000% CPU info: Celeron 2.8ghz, 256 KB cache Image Window size: 1007x1003 Screen resolution: 1280x1024 Reducing window size also reduces lag. This suggests to me the lag is related to the display code. What I do not understand is how EVENT_FILL_PRECISION can effect this.. wait a minute, yes I can. It depends on how smart the display update queueing is. If it's not particularly smart, queueing extra updates per pixel will slow things down. I'd guess if this is the case, then your code could be queuing multiple redraws per pixel for even modest zooms, but I don't notice it because my CPU can handle it; it's only when each area to update becomes large (4900 .. 65536 screen pixels per image pixel, aka 7000%..25600% zoom) that the problem becomes apparent.
I cant replicate it and heres the nag. There is no fill for zoomed in cases. The code is never called because of this if: if((distance >= EVENT_FILL_PRECISION) && event_fill && (shell->event_history->len >= 2)) And distance here is distance in image coordinates, not screen coordinates. At those zooms distance in image coordinates is hardly ever even a full pixel. This if is as far as it goes. The event evaluated gets queued and committed to move the cursor. Could you run top next to gimp when testing? whats eating the CPU? The only component I can suspect is your X/graphics driver ... I have Intel Core duo 2.00GHz Full screen image window on 1440x900 screen... Can anybody else replicate what David has?
I can do that. however, what i was saying doesn't require any filling to be done, it just requires the smoothing code to cause a region to be requested to be redrawn. I'm assuming this is because a sensible update policy without smoothing implemented is not necessarily a sensible update policy *with* smoothing implemented. top says: CPU usage: 39% gimp 9% xorg negligible% [everything else] trying again: 89% gimp 12% xorg So I think it's still GIMP, unless you are getting much lower xorg percentages. Oh, one more bit of information, WM: AwesomeWM (though I don't regard this as significant, since the behaviour occurs whether the image window is in a tile or (as GIMP might usually expect) a floating window.)
The catch is, there is no smooth for below 100% zooms. Ever. not any kind. you don't need it as a rule so it is not done. if it would be redraw, you would get the same effect with tablet. the code path is same, and tablet provides more events to travel down it so it should suffer more. My top has metacity on first place in CPU usage with about 50%. then Xorg with about 30% and then gimp with about 18% the same. + a few % of insignificant stuff. It seems WM could be a significant factor. Can you run a test with using metacity? Hows your memory usage? One thing that does depend on the filter level is how big the que grows maximally and how much memory it consumes. That memory is not released once reserved because reserving memory is expensive... If you start gimp and directly go to high zoom drawing, without touching the canvas first, if its a memory issue, the slowdown should not be there because cues have not been used yet. however, the max que length Ive managed to generate is below 50 events, and events are not that big byte wise. The whole que (estimating here that the coords struct is about 4x10=40 bytes, 50 events) is then no more than 2kb... Insignificant...
One thing is that I'm not using .. 'xgl'? the fancy compositing/ 3d deceleration x server, because they made gimp very sluggish. I'll try metacity (if it will work without xgl). Sorry, just to clarify, the effect does occur with tablet at very high zooms. (it's just harder to tell whether I or GIMP are the cause of the delay, at that zoom) in fact, if I do something as simple as click somewhere, then shift-click somewhere else, there is still a noticable delay. Slowdown always occurs, whether I check immediately or after a while. One other thing is that simply moving the mouse quite slowly across the image can increase gimp CPU usage to 62% (the remainder is used up by xorg). this completely baffles me. Dependency crisis occurred here, which took some time to fix, so I'll try metacity (and the latest git version of awesomeWM) tomorrow.
I dont use any 3d compositing wm-s either. metacity is a plain oldschool 2d wm. Sure the effect is not there without the patch?
Actually, the effect is there without the fill patch, sorry. Metacity gives identical results, both in CPU usage and slowdown. Looks like I need to report a separate bug.
Created attachment 125977 [details] [review] Updated event fill 4 Cleaned up by Sven(Thanks :D ) and last bugs (two border conditions, that made it not work 100%) squashed.
http://bugzilla.gnome.org/show_bug.cgi?id=127785 is a bug also fixed by this patch. Just noting it up here so it wont be forgotten.
Created attachment 126149 [details] Before-After sample for the fill patch
Very nice work :) Now committed to trunk: 2009-01-10 Sven Neumann <sven@gimp.org> Bug 471344 – Circular brush strokes are not smooth and have corners Bug 127785 – stroking with size linked to pressure sensitivity should scale the spacing * app/core/gimpcoords-interpolate.[ch] * app/display/gimpdisplayshell.[ch] * app/display/gimpdisplayshell-callbacks.[ch] * app/display/gimpdisplayshell-coords.[ch]: applied patch from Alexia Death that introduces a Catmul-Rom splines based event interpolation and also adapts the brush spacing to brush size.
*** Bug 589929 has been marked as a duplicate of this bug. ***