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.

Re-assigning all Gimp bugs to default component owner (Gimp bugs list)

Reassigned to current CVS because it's a wishlist item.

*** Bug 65126 has been marked as a duplicate of this bug. ***

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

*** Bug 73350 has been marked as a duplicate of this bug. ***

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.

*** Bug 88964 has been marked as a duplicate of this bug. ***

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.)

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.

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.

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.

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.

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.

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.

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.

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.  ;-)

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.

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.

*** Bug 132025 has been marked as a duplicate of this bug. ***