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 32498 - Pointer should reflect toolsize (brush cursors showing brush size)
Pointer should reflect toolsize (brush cursors showing brush size)
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: Tools
git master
Other All
: Normal enhancement
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
: 65126 73350 88964 132025 (view as bug list)
Depends on:
Blocks: 104631
 
 
Reported: 2000-11-18 03:30 UTC by hazukaw
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description hazukaw 2001-01-28 16:03:23 UTC
Package: gimp
Version: redhat 7 -don't know a version

Name........: Witold Hazuka
Email.......: hazukaw@wp.pl
Platform....: redhat 7
GIMP Version: redhat 7 -don't know a version
GTK Version.: redhat 7 -don't know a version
WM/Version..: GNOME   RH 7 -don't know a version


-- Other system notes:


--

-- Problem description:
I thing there should be a circle showing a tool size (like in PHOTOSHOP)and it should change when the size of the tool changes.
I use it all the time,it is very helpfull.
--


-- How to repeat:

--


-- Other comments:
I've installed recently the RH 7 and I think it is much more proffesional system than WINDOWS.
I really would like to change to LINUX but there is some lack in programs,mostly 3D.
I work in architekture-visualisation and it is anough for me to have GIMP,COREL or something like this, and some GOOOOD 3D engine for visualisation.
For now, one can use COREL for LINUX,GIMP and some 3D programs.
Although the latest GIMP is much more like PHOTOSHOP,there is for me only one thing left to do -a circle showing tool size.
Don't be angry with me for the PHOTOSHOP, but for now
I think it is the leading program in graphics.
Please send me a note what do You think about it

--




------- Bug moved to this database by debbugs-export@bugzilla.gnome.org 2001-01-28 11:03 -------
This bug was previously known as bug 32498 at http://bugs.gnome.org/
http://bugs.gnome.org/show_bug.cgi?id=32498
Originally filed under the gimp product and general component.

The original reporter (hazukaw@wp.pl) of this bug does not have an account here.
Reassigning to the exporter, debbugs-export@bugzilla.gnome.org.
Reassigning to the default owner of the component, egger@suse.de.

Comment 1 Raphaël Quinet 2001-02-08 16:57:20 UTC
This improvement has been suggested several times on the gimp-user
and gimp-developer mailing list.  The usual reply to this suggestion
is that it is tricky to do that in X11 because most X servers have
some limitations on the size of the pointer that they can draw.

However, there are some X servers that would accept large pointers
and the GIMP is also available on other platforms that can display
large pointers (Windows, OS/2, Mac).  So it could be insteresting
to implement that feature even if it does not work everywhere.  A
fake pointer could also be used, similar to the one drawn when you
use a graphics tablet in "window" mode.
Comment 2 Raphaël Quinet 2001-04-26 18:11:19 UTC
Re-assigning all Gimp bugs to default component owner (Gimp bugs list)
Comment 3 Michael Natterer 2001-06-19 00:34:31 UTC
Reassigned to current CVS because it's a wishlist item.
Comment 4 Raphaël Quinet 2001-11-22 17:26:47 UTC
*** Bug 65126 has been marked as a duplicate of this bug. ***
Comment 5 Raphaël Quinet 2002-01-08 09:10:30 UTC
Additional information posted on the gimp-developers mailing list...

From <benr@cuddletech.com>:
> The only feature I miss when I use GIMP is that of Photoshop's brush
> cursors.  In Photoshop, when you choose a 12pixel brush, your cursor
> becomes a 12pixel sphere (or whatever shape of the brush) to
> illustrate where your paint is going to drop.  This is, IMHO, a very
> very useful image editing tool. [...]  I do a lot of image cleanup
> and when editing an image border (say, painting out a background)
> it's really helpful to know exactly which pixels are going to be
> changed.

From "Stephen J Baker" <sjbaker@link.com>:
> I'll second that one.  It's a pain not knowing where your brush will
> land - ESPECIALLY because when the image is zoomed in or out, the
> brush size can be much larger or smaller than you expect.
> 
> [...] It's not as simple as setting the X cursor to the right thing
> because when you are zoomed right in and painting with a huge brush,
> you can end up with a cursor that covers half the screen!

From "Mattias Engdegård" <f91-men@nada.kth.se>:
> For X11, using the ordinary cursor up the maximum size is obvious;
> whether then to use a masked pixmap or chain of line segments is a
> matter of benchmarking under different circumstances (remote vs
> local X server, different server cleverness etc).
> 
> For instance, a masked pixmap requires little bandwidth once it has
> been transferred to the server, but might be slow if the server
> handles sparse masked blits in a bad way. Line segments need more
> bandwidth per mouse motion but are potentially cheaper to render.
> Implementing either is not hard, but I (being primarily an Xlib
> programmer) don't know how if gdk/gtk have the necessary primitives
Comment 6 christo 2002-03-04 04:56:49 UTC
*** Bug 73350 has been marked as a duplicate of this bug. ***
Comment 7 Michael Alger 2002-07-06 14:15:45 UTC
Is anyone looking into this at all?

This would be a really nice feature to have -- good karma
opportunity here!

My feeling is that a dotted outline showing exactly which
pixels will be touched would be the most useful, although
it may be expensive to render.
Comment 8 Sven Neumann 2002-07-24 15:29:11 UTC
*** Bug 88964 has been marked as a duplicate of this bug. ***
Comment 9 Christoph Singer 2002-09-21 17:37:50 UTC
The lack of this feature is for what I hate working with the Gimp
(esp. retouching of photographs using the clone tool).
In fact, I don't know any other serious bitmap graphics program that
does not have this feature.
Though I'm not a programmer I believe that it should be possible to
implement this feature in an X environment because the alpha versions
of the KDE program KImageShop aka Krayon aka Krita had it (it's a pity
that this project obviously has died.)
Comment 10 Manish Singh 2002-09-21 17:52:12 UTC
Probably the best way to implement this under X is to use keithp's
Xcursor extension when it is ready. You can have nifty ARGB cursors.

I don't know how the functionality maps to other windowing systems,
perhaps an abstraction on GDK is warranted.
Comment 11 Simon Budig 2002-09-21 18:04:24 UTC
Using the Xcursor extension would make it dependant on X11, or even
worse on XFree86.

I think it would be enough to create an 1-bit outline of the brush
with the same algorithm as we generate the selection outline, maybe
with a different threshold. This could be superimposed on the image
within the draw routines.
Comment 12 Manish Singh 2002-09-21 18:27:04 UTC
Which is why I suggested putting such functionality in GDK. IIRC,
directfb has similar functionality. Windows may have similar as well.
Xcursor does have fallbacks to core cursors for non-RENDER X servers.
Of course, this can be a completely optional feature.

It is a win because the image data is transferred to the server only
once (especially with large cursors), and possibly hardware
accelerated alpha blending.
Comment 13 Simon Budig 2002-09-21 19:38:45 UTC
Ah, I accidentially ignored this part  :-)

But we have to make sure, that the image shown does not disturb too
much. Displaying the original brush might not be feasible because it
would cover the image and might disturb more than actually help.

Also for the clone tool the cursor-image would have to change frequently.
Comment 14 Raphaël Quinet 2002-09-23 08:46:19 UTC
I don't know if the GTK+ developers would be interested in adding this
feature to GDK, because this is quite complex and I do not think that
many applications would use it.

As mentioned during the previous discussion on the gimp-developer
list, there are some significant performance issues that depend on the
X server used (and being mostly a Solaris user, I don't think that a
XFree86-only solution would do much good if we do not also have a
generic solution).  If you re-read the comment from Mattias Engdegård
that I quoted above, you will see that the best solution for X11 is
to use the cursor bitmap up to the maximum size allowed by the
server, but for larger sizes this is more difficult because in some
cases it would be better to send a bitmap to the X server and in some
other cases it would be better to draw a set of line segments.  The
best solution depends on the X server used and on the size or
complexity of the brush (i.e., number of segments).  The last point
about the size and shape of the brush is very important because it
would be difficult to implement a generic solution in GDK.

Although this is rather low-level stuff and it would be nice to
abstract this away into GDK, I think that will will have to deal with
that in the GIMP itself.
Comment 15 Raphaël Quinet 2002-09-23 09:04:43 UTC
By the way, don't forget that one should be able to zoom in (1600%) and
use a large brush without killing the X server (or Windows or directfb)
or slowing it down to a point that the computer becomes unusable.
That's why I think that it is important to know when to switch between
full images and bitmasks or line segments.

Drawing the full brush image with alpha may be interesting when working
at 1:1 scale, but should probably be disabled (switching to outline
only) when zoomed in.
Comment 16 graeme worthy 2003-05-10 19:48:09 UTC
the 'magic-wand' has an interesting way of showing the size of the
area to be selected. It outlines the area in a grey, and then that
changes as you select different sections, as a preview. 

Perhaps this method could be applied to this problem, the cursor
wouldn't have to change size at all.
Comment 17 Raphaël Quinet 2003-05-14 18:34:03 UTC
The method used for the magic wand would probably not work well for
the paint tools because it would be too slow.  The pointer must follow
the mouse at any time and it would be annoying for the user if it was
lagging behind.

So I think that the solution outlined by Mattias Engdegård and refined
in later discussions is the most appropriate one: try to use the
ordinary cursor up to the maximum size supported by the X server (or
by Windows, or whatever system is used).  This will give the best
performance in any case.  For larger sizes, use a bitmask or a set of
line segments depending on what works best.  The "what works best"
part is tricky and depends very much on the shape of the brush and on
other parameters such as whether the brush is animated or not.

Side note: I discussed this briefly with Owen Taylor at FOSDEM three
months ago and he suggested doing this in the GIMP rather than in GTK+
because some parts of this code would be application-specific.  But
maybe he has changed his mind now.  ;-)
Comment 18 Nathan Summers 2003-05-15 18:38:42 UTC
If the brush size relative to the zoom factor is greater than about 
32x32 or so, it's unlikely that the user will need pixel-perfect 
positioning anyway, since the cursor is just so dang big and is 
therefore a very blunt instrument.  So perhaps the issue of what to 
do with unsupported cursor sizes isn't such a big deal.

On the other hand, if the zoom factor is greater than one, you have 
the problem that the boundaries of the mouse cursor won't line up 
exactly with the result, since the mouse cursor is effectively shown 
at a subpixel level.
Comment 19 Michael Natterer 2003-07-10 16:01:57 UTC
Added this feature to CVS HEAD:

2003-07-10  Michael Natterer  <mitch@gimp.org>

	* app/display/gimpdisplayshell-transform.[ch]: removed
	gimp_display_shell_transform_boundary() again...

	* app/tools/gimpdrawtool.[ch]: ...and added as
	gimp_draw_tool_draw_boundary(). Removed the GimpDrawToolState enum
	and the "draw_state" member since they were redundant. Cleanup.

	* app/tools/gimpeditselectiontool.c: changed accordingly.

	* app/tools/gimppainttool.[ch]: added a brush preview so we
	finally see where we will paint. Fixes bug #32498. Cleanup.

	* app/tools/tool_manager.c: also look at draw_tool->gdisp, not
	only at tool->gdisp when deciding whether the active tool has to
	be suspended/resumed/halted. Fixes a couple of fnords with the
	line preview and the new brush preview.

	* app/tools/gimpcolortool.c: minor cleanup.
Comment 20 Sven Neumann 2004-01-20 23:56:03 UTC
*** Bug 132025 has been marked as a duplicate of this bug. ***