Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Add hardware cursor support #9
Continuing from here: http://www.opentk.com/node/3443?page=1
This post describes how to implement hardware cursors on Windows: http://www.mimicprod.net/2010/09/hardware-cursor-in-opengl/
SDL provides a cursor API, but the documentation states that it is black-and-white only (it is possible that the documentation is out of date here.)
We still need to find out how this works on X11 and Carbon.
Ideally, our public API will take an array of 32bit RGBA values with a specific layout. This way we remain agnostic to any platform-specific cursor format (e.g. windows .ico files, .png images etc etc) and we avoid System.Drawing which is broken and not portable.
This comment has been minimized.
This comment has been minimized.Show comment Hide comment
Did some work on Windows support. https://github.com/Frassle/opentk/tree/cursor
referenced this issue
Mar 18, 2014
added a commit
Mar 19, 2014
This was referenced
Apr 24, 2014
Initial support for switching between
What we are now missing is support for byte-swapping (Rgba vs Bgra vs Argb) and a proper implementation for Cocoa.
@Ollhax any ideas?
What exactly is the issue here? Looking at the SDL docs color cursors are initialized by a surface that should define the pixel format.
@Frassle if you use a
We could always place this responsibility on the user ("cursors are argb little-endian, have fun figuring that out") or we could implement this internally. Seeing how much trouble I had getting the correct layout for SDL (it's still not correct in the repository), I'm inclined to go for the latter.
@Ollhax np, I've managed to get a custom cursor to saw up, but I didn't have any luck overriding
but this function was never called.
Edit: now that I see this, it could be that resetCursorRects is called on the contentView, not the window itself.
Edit 2: this is what I am trying to achieve:
I'd be inclined to think putting this on the user is the correct thing to do. We don't do format conversions anywhere else, if a user asks for an RGBA GL texture and then passes in ABGR they get the wrong result. As long as we well document the MouseCursor constructor I don't think people will struggle too much, also if we set the expected format to be whatever the default Drawing.Bitmap format is then for most people it will just work. We can then handle converting from one defined format to a platform dependent format in the Cursor setter.
I also can't see any way that the library could be expected to work out the byte order given any arbitrary user input anyway.
I was thinking about adding an extra parameter to the constructor similar to
I must say that I do dislike System.Drawing and would like to get rid of its perma-broken libgdiplus dependency eventually - but that's a different discussion entirely.
As part of OpenTK or as a separate library referenced by OpenTK? I saw there was some discussion on the MonoGame repo about something similar.
Either would be fine by me.
OpenTK already provides dummy implementations for System.Drawing
In the mid-term, I would like to remove all System.Drawing calls from the platform backends. This is why, for example,