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 421466 - green trailing lines from tools
green trailing lines from tools
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
2.3.x
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
: 404204 444291 487670 489618 492320 499053 501095 501399 504329 504728 504806 576939 582476 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-03-22 12:55 UTC by alan winn
Modified: 2009-05-13 17:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description alan winn 2007-03-22 12:55:57 UTC
Please describe the problem:
tool leave green trails of the tool outline across the image when mouse is not pressed (  out line is size of brush). Happens on all 'brush' tools clone, brush, eraser etc

Changing zoom option clears them but they reappear when brush moves over image

Steps to reproduce:
1. Happens everytime
2. 
3. 


Actual results:


Expected results:


Does this happen every time?
yes

Other information:
Running gimp-2.3.14-1.mde2007.0.i586 on mandriva 2007 have tried other rpms with same effect (gimp-2.3.14-1zae.i586) graphics card is ATI Radeon 7000 running on mandriva supplied ATI Radeon driver.

No problem with any version up to 2.3.14
Comment 1 Simon Budig 2007-03-22 13:45:52 UTC
Thanks for your report.

I'd guess that this is a driver problem with the X server - apparently the XOR-drawing leaves traces. To verify this, could you please tell us if this looks green against a black background and violet against a white background (We changed the color of the XOR drawing recently)?

If this indeed is the XOR drawing there unfortunately is not much we can do about this. You could try an alternate graphics driver for your card and see if the problem persists. This would be outside our scope then.

Since it seems to work ok for most other people I strongly suspect the driver...

Bye,
         Simon
Comment 2 alan winn 2007-03-22 14:04:27 UTC
(In reply to comment #1)
> Thanks for your report.
> 
> I'd guess that this is a driver problem with the X server - apparently the
> XOR-drawing leaves traces. To verify this, could you please tell us if this
> looks green against a black background and violet against a white background
> (We changed the color of the XOR drawing recently)?
> 
> If this indeed is the XOR drawing there unfortunately is not much we can do
> about this. You could try an alternate graphics driver for your card and see if
> the problem persists. This would be outside our scope then.
> 
> Since it seems to work ok for most other people I strongly suspect the
> driver...
> 
> Bye,
>          Simon
> 

Thanks Simon

Changing to Radeon fbdev and enabling transparency cured it.
I assume that 2.3.14 is more graphics  intensive.

Best wishes

Alan Winn

www.2d.uk.com
Comment 3 Simon Budig 2007-03-22 14:31:23 UTC
Well, it is not really more intensive. A difference is though, that earlier we used XOR-drawing with the color #ffffff, while we now use the color #80ff80, which has the advantage to always give a contrast to the original color. It is possible that this triggers a different code path in the driver, which uses a different algorithm for line interpolation.

I'll change the resolution to NOTGNOME, since this is not in our codebase.

Thanks for verifying this.
Comment 4 Sven Neumann 2007-03-22 19:10:18 UTC
We should probably add a preference option to change to the old XOR drawing code. That would allow people who are forced to work with broken drivers to easily work around the problem.

The debian package for 2.3.14 contains a patch that reverts the XOR drawing changes. This is IMO a bad idea but we could avoid such hacks by making this configurable.
Comment 5 Sven Neumann 2007-03-23 09:28:52 UTC
2007-03-23  Sven Neumann  <sven@gimp.org>

	Make XOR color configurable (bug #421466):

	* app/config/gimprc-blurbs.h
	* app/config/gimpdisplayconfig.[ch]: added gimprc option for the
	XOR color.

	* app/display/gimpcanvas.[ch]: keep a reference to the Gimp object
	and take the XOR color from GimpDisplayConfig.

	* app/display/gimpdisplayshell.c: pass gimp to gimp_canvas_new().
Comment 6 Sven Neumann 2007-10-18 06:24:26 UTC
*** Bug 487670 has been marked as a duplicate of this bug. ***
Comment 7 Michael Schumacher 2007-10-24 08:48:28 UTC
*** Bug 489618 has been marked as a duplicate of this bug. ***
Comment 8 Eric Seppanen 2007-10-25 21:07:09 UTC
I'm afraid the gimprc xor-color option has little effect on this problem.

I tried both (xor-color (color-rgb 1.0 1.0 1.0)) and (xor-color (color-rgb 0.0 0.0 0.0)), and the only effect is that I get white trails or blacks trails across the image instead of green ones.
Comment 9 Raphaël Quinet 2007-10-26 06:11:02 UTC
(In reply to comment #8)
> I'm afraid the gimprc xor-color option has little effect on this problem.
> 

A more recent change should fix the problem:

2007-10-25  Sven Neumann  <sven@gimp.org>

	* app/display/gimpcanvas.c (gimp_canvas_gc_new): use INVERT
	instead of XOR if the xor-color is configured as white.

This will be part of GIMP 2.4.1. Feel free to r-open this bug report if you still see this problem after upgrading to 2.4.1 (once it is released).
Comment 10 Michael Schumacher 2007-11-01 11:26:43 UTC
*** Bug 492320 has been marked as a duplicate of this bug. ***
Comment 11 garkein 2007-11-20 20:03:11 UTC
I upgraded gimp from 2.2 series to 2.4.1 from Debian yesterday (2.4.1-1) and since then suffer from the above problem.
(Debian Testing, radeon driver)

Any more infos needed?
Comment 12 Sven Neumann 2007-11-20 21:11:18 UTC
Why don't you use the workaround and add

 (xor-color (color-rgb 1.0 1.0 1.0))

to your gimprc file until someone eventually fixes the driver?
Comment 13 garkein 2007-11-20 22:15:32 UTC
Because until your current comment it was, for a mere gimp user, completely unclear what exactly to add where. Sorry if I missed a FAQ or README - if that above mentioned workaround requires the user to manually add some statement to a config file, it should be stated somewhere. 

I will try. :)
Thanks.
Comment 14 garkein 2007-11-20 22:39:44 UTC
Thank you. It seems to work.
Comment 15 Sven Neumann 2007-11-20 22:48:52 UTC
It's a workaround and you are missing functionality with it. You should not forget to make sure that this is fixed in your graphics card driver at some point so that you can remove the workaround.
Comment 16 Michael Schumacher 2007-11-22 22:16:09 UTC
*** Bug 499053 has been marked as a duplicate of this bug. ***
Comment 17 Martin Nordholts 2007-12-02 21:41:12 UTC
*** Bug 501095 has been marked as a duplicate of this bug. ***
Comment 18 Michael Schumacher 2007-12-03 23:02:17 UTC
*** Bug 501399 has been marked as a duplicate of this bug. ***
Comment 19 Sven Neumann 2007-12-18 20:45:15 UTC
*** Bug 504329 has been marked as a duplicate of this bug. ***
Comment 20 Michael Schumacher 2007-12-20 19:39:09 UTC
*** Bug 504728 has been marked as a duplicate of this bug. ***
Comment 21 Martin Nordholts 2007-12-21 06:50:27 UTC
*** Bug 504806 has been marked as a duplicate of this bug. ***
Comment 22 Michael Schumacher 2008-08-26 15:04:48 UTC
*** Bug 444291 has been marked as a duplicate of this bug. ***
Comment 23 Michael Schumacher 2008-08-26 15:06:11 UTC
*** Bug 404204 has been marked as a duplicate of this bug. ***
Comment 24 Michael Schumacher 2009-03-27 12:24:49 UTC
*** Bug 576939 has been marked as a duplicate of this bug. ***
Comment 25 Michael Natterer 2009-05-13 17:07:27 UTC
*** Bug 582476 has been marked as a duplicate of this bug. ***