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

[void256]

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

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

[ajr_1]

This sounds similar to my issue, see here:

http://lwjgl.org/forum/index.php/topic,4711.msg26339.html#msg26339

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

[3xp0n3nt]

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

[noblemaster]

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?

[void256]

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 

[kappa]

cool, thanks for finding and fixing.

patch merged.

[ajr_1]

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