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 148202 - XOR drawn lines are hard to see
XOR drawn lines are hard to see
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
unspecified
Other All
: Normal enhancement
: Future
Assigned To: GIMP Bugs
GIMP Bugs
: 315152 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-07-22 19:54 UTC by Ryan Saunders
Modified: 2006-12-14 07:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ryan Saunders 2004-07-22 19:54:48 UTC
When using the Crop tool on an image with a mostly transparent background, it
can be very difficult to figure out where the crop region is, since the lines
and corner drag-boxes can almost completely blend into the bi-level grey checker
pattern indicating transparency. Something a little more noticeable, perhaps
black corner boxes with a white outline...
Comment 1 Sven Neumann 2004-07-22 23:46:31 UTC
This is a general problem with XOR drawing. It isn't visible on gray areas. This
would be a substantial change though and won't happen for 2.2.
Comment 2 Albert Cahalan 2005-01-22 23:22:52 UTC
XOR each channel with 0x80, not 0xFF.
Worst case is then black, assuming sRGB gamma.
There will be a discontinuity at 0x7f and 0x80;
this is better than being invisible.

Comment 3 Joao S. O. Bueno 2005-01-23 03:23:54 UTC
And this is actually resolved for the Crop tool - as the cropped-out area is 
now shaded. Nonetheless the bug stands for other drawn items, like Paths. 
 
Comment #2 seens a reasonable solution - and possible use just black instead 
of XORing, if the color is close to mid gray could be better. 
 
 
Comment 4 weskaggs 2005-01-23 17:26:23 UTC
XOR drawing has a very special property:  if you draw something twice, the
second time "undraws" it, producing a result that exactly matches the original.
 Many things in GIMP are written to depend on this property, so changing to a
mode other than XOR would be highly nontrivial.
Comment 5 Sven Neumann 2005-09-03 06:17:00 UTC
*** Bug 315152 has been marked as a duplicate of this bug. ***
Comment 6 Sven Neumann 2005-09-03 13:19:52 UTC
We are all looking forward to replace the canvas drawing code with an
implementation based on cairo (http://cairographics.org). That is however most
likely not going to happen for GIMP 2.4 because we really need to get that out
of the door soon and shouldn't start more major changes.
Comment 7 Nick Smith 2005-10-16 23:21:06 UTC
One way to work around this is to find a contrast, a brightness of a color.  A
decent estimation formula would be something like this:

RED*80/255 + GREEN*107/255 + BLUE*68/255

If the result of the selection outline to this color is 127 or less (dark), a
white outline is used.  If 128 and above (to 255; light), black is used instead.
 This might be a temporary workaround you could consider for this.  This formula
isn't exact, but it's fairly close and would provide sufficient contrast for
selections on any background.
Comment 8 Sven Neumann 2005-10-17 10:46:16 UTC
Nick, are you sure that you understand what XOR drawing means and why it is
being used here?
Comment 9 Sven Neumann 2006-12-14 07:16:45 UTC
At some point we will want to stop using XOR drawing for most things. That will probably happen when we port tool drawing to Cairo. In other words, after 2.4 is out. But for now, Simon has found a nice workaround:

2006-11-23  Simon Budig  <simon@gimp.org>

        * app/display/gimpcanvas.c: Change the color for XOR drawing. This
        guarantees that there is always a contrast between the original
        image pixels and the stuff drawn on top of it.