Hello Guest

[FIXED] mouse cursor with LWJGL 2.9.0 on Mac OS X displays wrong (sometimes)

  • 6 Replies
We've successfully loading custom mouse cursors for a long time using something like:

Code: [Select]
ByteBuffer imageData = imageLoader.loadMouseCursorImage(source);
int width = imageLoader.getWidth();
int height = imageLoader.getHeight();
return new Cursor(width, height, hotspotX, height - hotspotY - 1, 1, imageData.asIntBuffer(), null);

But now that we've switched to LWJGL 2.9.0 we experience random display errors of the mouse cursor when running in Mac OS X 10.8.3 and Java 6.

It's a bit like lottery ;) We run the same program all the time and we have something like a 20% chance of getting the correct mouse cursor image to show up. In the other cases we get something that looks like a random bit pattern to me. You know, like when a random piece of memory is being used as an image. Unfortunately I can't make a screenshot since the OS X native screenshot tools hide the mouse cursor and screenflow only shows the standard cursor in the recording.

When we change back to LWJGL 2.8.x it works again. So I guess there might be some issue with LWJGL which is probably related to the new implementation for Mac?

Any ideas?  ???
« Last Edit: May 25, 2013, 16:07:02 by kappa »


Offline ajr_1

  • *
  • 23
This sounds similar to my issue, see here:


I've not been able to figure out how to fix it though. 

@ajr_1 I've got the same issue. The mouse cursor looks exactly the same as in your picture.

Same problem here! I never had problems with LWJGL 2.8.0.

In 2.9.0 sometimes the cursor displays correctly (about 50% of the time). Otherwise, the cursor displays the same as the other users reported. One time I got the cursor to display half correct: the bottom pixels were correct but the pixels above where garbaged! Maybe the byte buffer used to create the native cursor is released to early while the cursor is still being created?

I think I've fixed that now. See this pull request for details: https://github.com/LWJGL/lwjgl/pull/33

The problem was, that the NSBitmapImageRep used does not make a copy of the image data given, at least not by default. We have to kinda tell it to make a copy which solved the issue as far as I see  8)


Offline kappa

  • *****
  • 1316
cool, thanks for finding and fixing.

patch merged.


Offline ajr_1

  • *
  • 23
Just confirming that this works for me.  Thanks @void256 and @kappa!