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 577575 - transform tool fills underlying extracted area wrongly
transform tool fills underlying extracted area wrongly
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal normal
: 2.6
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2009-04-01 03:56 UTC by david gowers
Modified: 2009-04-03 14:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description david gowers 2009-04-01 03:56:33 UTC
.. It fills with an arbitrary color, rather than the background color.

Steps to reproduce
1. Pick some random color as background color
2. Open an image. Make sure the layer has no alpha channel
3. Select part of the image using freehand-select tool
4. Rotate that part
5. See that the 'holes' are not filled with BGcolor but some other color.

For Jay Smith (2.6.6 on Ubuntu Linux), the 'arbitrary color' is white; for me (SVN on Ubuntu Linux) it is black.

If you float the area before rotating it, you can get a correct result (in which the 'hole' is always filled with BGcolor)
Comment 1 Michael Schumacher 2009-04-01 08:52:24 UTC
I'm seeing the white in 2.6.5. Confirming.
Comment 2 Jay Smith 2009-04-02 14:23:11 UTC
Jay Smith, discoverer here. Available to test fixes. (Gimp 2.6.6 on Ubuntu Linux)

We have had similar problem -- but not consistently repeatable -- so far with _moving_ a selected part of the image.  For me, _sometimes_ such a move fills the "moved away from area" with white even though background color is set to black and even though the create-new-image preference for new images is to fill with background color.  There seems to be some relationship -- but have not been able to figure it out to make it repeatable yet -- with images created by scanning using Xsane from within Gimp, where as creating an image in Gimp with the New... is not today showing this fill problem when _moving_ an image (but is with rotate).

Comment 3 Michael Natterer 2009-04-02 19:45:13 UTC
Obviously broken, but I fixed it locally. The fix does surgery deep in the
generic tool options property handling, so I'd like to test it for
some days before committing. Stay tuned.
Comment 4 Michael Natterer 2009-04-03 14:06:16 UTC
Seems the surgery mentioned above was the wrong fix. It all works as intended
if the tools use the API they should for getting access to the global BG
color.

Fixed in both branches:

2009-04-03  Michael Natterer  <mitch@gimp.org>

	Bug 577575 – transform tool fills underlying extracted area wrongly

	* app/tools/gimpfliptool.c
	* app/tools/gimpperspectivetool.c
	* app/tools/gimprotatetool.c
	* app/tools/gimpscaletool.c (gimp_*_tool_register): pass
	GIMP_CONTEXT_BACKGROUND_MASK to the register callback to the tools
	use the global background color.