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 68542 - many selection-outline turds
many selection-outline turds
Status: VERIFIED DUPLICATE of bug 22375
Product: GIMP
Classification: Other
Component: Tools
1.x
Other All
: Normal normal
: ---
Assigned To: GIMP Bugs
Daniel Egger
Depends on:
Blocks:
 
 
Reported: 2002-01-11 23:36 UTC by Jamie Zawinski
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
screen shot of lossage (170.08 KB, image/gif)
2002-01-18 01:39 UTC, Jamie Zawinski
Details

Description Jamie Zawinski 2002-01-11 23:36:43 UTC
A lot of the time when I select a region (rectangle or lasso) and
copy/paste/move it, I get noise lines drawing toward the corners of the
screen: as if, in the process of drawing the poly-line around the
selection, it decided to draw some of those line segments to 0,0 or 0,99999
or something.  Also, I sometimes see "shadow" outline boxes moving in sync
with the floating layer I'm moving, but not on top of it  (e.g., a few
inches down and to the left.)  These shadow boxes tend not to erase
themselves.

The lines go away when I finally paste, or sometimes when I cause the
window to be repainted.

I haven't been able to figure out exactly when this happens, but it happens
often.  Not always.

I have seen this on an SGI O2, as well as on Red Hat 7.2 Linux on an x86
with a Matrox G450 card.  So I think those two systems kind of rule out it
being a video card issue.

I think I've only seen it in docuements with multiple layers, and only in
rather large documents.  Of course, that's most of what I edit, so that
doesn't narrow it down much...

Feel free to /msg me ("jwz") on gimpnet if you want me to try anything to
narrow this down more.
Comment 1 Raphaël Quinet 2002-01-16 13:58:36 UTC
I remember seeing a similar problem some time ago on SuSE Linux (x86)
so I can confirm this bug.  Unfortunately, I haven't been able to
reproduce the problem recently.  There are other problems related to
the way the selection lines are drawn (sometimes they are not erased
correctly if canvas size != layer size) but the one you describe
(lines going towards the corners of the screen) did not happen to me
for a while.  But then again, I do not work on the same kind of images
as you do.
Comment 2 Jamie Zawinski 2002-01-18 01:39:41 UTC
Created attachment 6431 [details]
screen shot of lossage
Comment 3 Jamie Zawinski 2002-01-18 01:41:27 UTC
The above attached file shows what I'm talking about;
I see this behavior about 9 times out of 10 when I:

  - have a transparent layer with text on it
  - select a rectangle around some text
  - move

I see it other times too, but that's a pretty reproducible
way to make it happen.

It seems unrelated to zoom level.

I can't figure out what's different on the occasions where
everything works correctly.  I suspect it's just random.
Comment 4 Michael Natterer 2002-03-19 13:19:46 UTC
Seems I have fixed this in HEAD, but I'm not sure. Please test
if it still occurs.

2002-03-19  Michael Natterer  <mitch@gimp.org>

  * app/tools/tools-types.h: added enum GimpMotionMode which can be
  one of { EXACT, HINT, COMPRESS }.

  * app/tools/gimptool.[ch]: removed tool->perfectmouse and added
  tool->motion_mode. Default to GIMP_MOTION_MODE_HINT.

  * app/tools/gimpinktool.c
  * app/tools/gimppainttool.c: set GIMP_MOTION_MODE_EXACT.

  * app/tools/gimpfuzzyselecttool.c: set GIMP_MOTION_MODE_COMPRESS.

  * app/tools/gimpeditselectiontool.[ch]: ditto. Removed
  gtkutil_compress_motion().

  * app/display/gimpdisplayshell-callbacks.c: look at
  active_tool->motion_mode and perform pointer grabbing and motion
  compression accordingly. Also, don't request motion hints from
  XInput devices because the wacom driver sends crap (fixes #6901).
  This change also brings hints and ordinary motions back in sync
  albeit compression, so IMHO it also fixes #68542 and #22375, but
  this needs further investigation.
Comment 5 Michael Natterer 2003-04-13 11:53:20 UTC
Now I'm sure this is a duplicate.


*** This bug has been marked as a duplicate of 22375 ***
Comment 6 Raphaël Quinet 2003-06-20 17:03:52 UTC
The fix for bug #22375 is part of the stable release 1.2.4.  Closing
this bug.