I’ve looked into this more closely and believe we should “wontfix” this bug. Java’s XToolkit implementation uses xcreatepixmapcursor internally, which only supports setting a fore- and background color. As far as I can tell the xcursor extensions support setting cursors in ARGB format, which would allow a lot of colors as well as alpha transparency. However, it is not implemented. Therefore we would have to patch the JVM or ship our own xcursor implementation/bindings to gain hardware support. I’ve opened a feature request for just that(1).
The thread linked above is 404 by now, but the “solution” likely was to hide the cursor using a transparent image and instead paint it onto a glass pane yourself. This works, but the cursor will be rendered less often if the content behind the glass pane takes longer to paint. This is very similar to the way the helper line works, if it lags for you now, so will the cursor. I haven’t tested exactly, but my system would be fast enough if target highlighting is deactivated. The small delay caused by the highlights is already enough to make the cursor feel sluggish. For slower systems it might lag behind regardless if highlighting is on or off.
Thus it would not be possible to turn on the “colored cursor hack” for X systems by default, making this a niche solution. Plus, the workaround is ugly.
If anyone wants to try, I’ve attached a hacked GlassPaneDemo that has this implemented. The larger the window, the more buttons to draw, the laggier the cursor. JOSM’s map drawing works a little bit different, so it’s not exactly comparable, but it’s enough to get an idea.
Long story short: waiting for upstream to fix this is probably the best solution. If anyone objects, please reopen the bug.
(1) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7158547 (404 as of writing, but the mail said it should be online in a few days)
