GNOME Bugzilla – Bug 166622
Brush drawing can produce wrapped results with even-dimensioned brushes
Last modified: 2006-08-15 17:22:34 UTC
if a brush's width is even, it may be drawn wrongly. this is the smallest test case: 1. Create a new 4x1 image, and zoom in a lot. 2. Place a different color at the left and right ends 3. Blend between them using penciltool and opacity adjustment 4. select the two middle pixels and make a brush from them using script-fu->selection-> to brush 5. erase the middle two pixels. 6. select the new brush, and choose pencil tool. 7a. click on the right hand pixel of the middle two. this produces correct results. 7b. undo. click on the left hand pixel of the middle two. the left pixel of the brush is drawn on the right, and the right pixel of the brush is drawn on the left. this offsetting occurs along both the x and y axis (tried with a 2x2 brush and a 4x4 brush). in all cases the brush pixels are offset exactly 1 pixel in whichever axis.
I can confirm this with current cvs. The recipe given above is far more complicated than necessary, though -- if you create a brush with an even dimension, then depending on where the cursor is located within a pixel, the left or top edge of the brush mask will be rendered at the right or bottom side.
I just noticed this related effect: * Add 'test2.gbr' and 'test3.gbr' (attached) to your brushes dir. * Create a new white image * Select 'test!' (this is a even-width brush) * Scribble on the image using pencil tool for a while * Notice the black pixels appearing: there are no black pixels in the brush at all, though! test3.gbr (which is named 'Test!!' in gimp), has a column taken out, so it is odd-width and therfore doesn't trigger this bug. Included for purpose of comparison.
This problem also seems specific to RGB(A) brushes. I cannot reproduce it with greyscale brushes.
Created attachment 51731 [details] test2.gbr whoops, forgot to attach these.
Created attachment 51732 [details] test3.gbr whoops, forgot to attach these.
*** Bug 325323 has been marked as a duplicate of this bug. ***
Attached is a patch that seems to fix both of the problems reported here (they are actually the same problem manifesting itself in different ways). I have tested it pretty extensively, using a variety of pixmap brushes of different dimensions, and it seems to do the right thing in every case I have looked at. I have no idea why it works, though -- I got to it more or less by trial and error.
Created attachment 67444 [details] [review] proposed patch for app/paint/gimpbrushcore.c
Works for me :) It should certainly make it into 2.4. The actual culprit is probably elsewhere -- from the way this patch fixes it, I suspect the handling of the sampling kernels, which may be very difficult to pinpoint it in.
Will someone at least set the milestone to 2.4? I think it should be quite clear that having half of all possible brushes intermittently draw wrongly is a serious flaw. I've been using this patch for a few months now: it has no bad effects and works completely. It seems ready to commit.
Indeed, setting milestone. Will look at the patch again later today.
The patch looks somewhat weird but if it fixes the problem, let's get it into CVS for 2.4. Perhaps add a reference to this bug to the code.
Applied to HEAD, with reference to this bug added as suggested: 2006-08-15 Bill Skaggs <weskaggs@primate.ucdavis.edu> * app/paint/gimpbrushcore.c (gimp_brush_core_color_area_with_pixmap): kludge to adjust offset for even-dimensioned brushes; fixes bug #166622.