GNOME Bugzilla – Bug 116765
Display artifacts when dragging a selection
Last modified: 2004-12-22 21:47:04 UTC
Part of the image is not moved (or some trails are left) under certain conditions while dragging a selection. Steps to reproduce: 1. Create a 10x100 image and fill it with default black FG color, or load one with many colors. 2. Zoom to 5:1. 3. Edit->Select All. 4. Scroll to the bottom of the image. 5. Drag the selection down a few pixels, then right a few pixels. 6. Scroll to about y=64 and see some pixels that should be white or transparent but are black or copied from the image being dragged. It's a display artifact only. Undo+Redo solves the problem. The exact position where the artifact appears depends on the zoom ratio among other things, and the height of the band depends on how much the selection was moved down before moving it right (or left). If the selection is moved up instead of down in step 5, nothing strange seems to happen.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
Can be reproduced with 1.3.16 - do not resize the image window, just use the initial size. There stays a black rectangle at around y=64. Creating a new transparent layer gets rid of it.
Is this still reproducable? I assume that the menubar needs to be switched off. Is that correct?
Yes, it's still reproducable with yesterday's CVS version either with or without a menubar. What worries me about this problem is where the data that isn't written where it should is actually written. Additional note to reproduce it: don't touch the original window height, or do a shrink wrap (^E) right after creating it, but don't enlarge the window vertically during the rest of the steps. Of course step 3 should read: "Select->All" and not "Edit->Select All".
Why haven't I been able to reproduce it then? Perhaps I just didn't try hard enough...
Is still still reproducable after Mitch fixed bug #126942 ?
Yes, it's still reproducable. Note that this is not an exposure problem at all - indeed the wrong part is not visible until you scroll up. It's unaltered by zoom changes. The color picker does not see the wrong data. Manually calling gimp-drawable-update from the Script-Fu console gets rid of the artifacts as well, but a call to gimp-displays-flush doesn't. Additional note: the same problem happens if the full layer is moved instead of the selection using the move tool (no need to fill it black in that case). To make it clear, here's another step-by-step guide on how to reproduce it: 1. Create an image, width = 10, height = 100 2. Shrink wrap (^E). 3. Zoom to 500%. Don't resize the window (the Resize Window on Zoom option in the preferences should be disabled). 4. Scroll down to the BOTTOM of the image. The lower border should be visible at this point, and the upper should be hidden. 5. Select the Move tool. Be sure that the Transform Layer tool option is active. 6. Drag the layer diagonally down and to the right about 45 degrees, until (say) about 2/3 of the layer are off the image boundaries. 7. Scroll up to about y=64. I'm attaching a screenshot to show the result.
Created attachment 21809 [details] Screenshot of the problem described in bug #116765
The following patch works for me. However I'm far from being confident that it is valid or even that it doesn't break anything, and so I'd like to see it reviewed for correctness before committing it. As a tip for reviewers, this patch makes the value of "starty" be 64 on every call to gimp_image_construct() instead of letting it change (65, 66, 67,...) as the layer position changes when following the steps needed to reproduce this bug. Note also that the same problem could be reproduced horizontally by following the same steps but transposed (shrinking the window in the X dimension was necessary to see the effect).
Created attachment 21938 [details] [review] Patch that might fix bug #116765
Fixed in CVS: 2004-01-12 Michael Natterer <mitch@gimp.org> * app/core/gimpimage-projection.c (gimp_image_invalidate): applied patch from Pedro Gimeno that makes sure we always invalidate complete tiles, not parts of it. Fixes bug #116765. * app/display/gimpdisplay.c (gimp_display_paint_area): calculate the image area to invalidate using sub-pixel precision and ceil()/floor() the resulting area to make sure we always invalidate a superset of the dirty area, not a subset. A rounding error here has never been reported but would cause effects similar to #116765.