Better cursor support?

melekor wrote on Wednesday, May 11, 2005:

It would be great if GLFW had some functions that let you modify the system cursor, like CreateCursor, DeleteCursor, SetCursor, ShowCursor, HideCursor, etc.

This would be a much better solution than actually drawing the cursor manually with OpenGL, because that would require a SwapBuffers() every time the mouse moves.

To give an example of where this is useful: I am currently writing a custom OpenGL GUI using GLFW and the cursor needs to change when the user has the mouse over certain elements such as resizable frames. I have tried drawing the cursor through OpenGL, and it is unacceptable. Not only does it need thousands of times more redrawing, but if you move the mouse fast enough you can tell that it’s lagging a bit since OpenGL doesn’t redraw as fast as the system cursor, especially with a complex scene.

I would be willing to write the windows code myself (in fact, I will probably end up doing it anyways). I hope that support for other OSes is possible and that you might consider adding this kind of support to GLFW.

Please let me know what you think.


kohaistyle wrote on Thursday, May 12, 2005:

Honestly, i think this kind of feature has nothing to do with GLFW: it would mean hacking the OS system message pump, for no benefit at all …

melekor wrote on Friday, May 13, 2005:

I can see where you’re coming from kohaistyle. This feature isn’t directly related to OpenGL.

However, GLFW is more than just an OpenGL setup lib, it is meant to provide some basic features of the window system as well, and it’s already doing a good job. I just recently noticed that cursor support was lacking.

You said “it would mean hacking the OS system message pump, for no benefit at all …”. I’m not sure why you think this is any more of a “hack” than anything else GLFW currently does like creating a window, etc. Also, I went in depth in my first post about why I feel that this feature is necessary. Why do you say that it will have no benefit at all? Please explain.

I appreciate your input.


melekor wrote on Friday, May 20, 2005:

Marcus? Anyone?

It’s been over a week now. If this has no chance of getting into GLFW, you can tell me straight up, but please don’t ignore this thread.

I need this functionality for my program, so I will be getting it one way or another. I just thought that it fits within GLFW’s realm and that it would be a nice addition to the library.

Like I said earlier, I can provide the windows version of the code. I might also be able to get the OS X version from a friend. So it’s not like I’m asking you to write all the code for me :slight_smile:

What do you say?


wesleyhill wrote on Friday, July 01, 2005:

I was just about to ask for the same kind of functionality. I’m writing an RTS engine, and RTSs traditionally use the cursor a lot to give cues to the user about what will happen if they click in spot X for example.

The problem is if I draw the custom cursors myself with OpenGL in the main loop, then the cursor refresh rate gets tied to the frame rate of the game, which can be quite disconcerting to the user when the frame rate drops below a ‘smooth’ level for whatever reason. Worse still, if the loop hangs then the user is liable to believe that that the OS has hung too, since they’re used to the mouse still moving even when an application appears frozen.

One solution would be to create another thread to draw the cursor. This has the problem where it’s hard to make sure the cursor thread runs at a firendly rate: set the priority higher than the game and the OS could neglect to run the game, set it to the same or lower priority and the cursor is back to moving at a jerky rate since the game likes to chew cpu time. Also, the cursor thread will have to be writing to the front buffer not the back buffer, or it’s again stuck to the same speed as calls to glfwSwapBuffers().

So a much nicer solution would be let the OS handle the cursor as it usually does. And GLFW, being a platform wrapper for these kind of calls, is the perfect place to do it. More than that though, it is the only place that _can_ do it, since only it knows things like window handles, and under windows, the window class cursor needs to be set to NULL before the call to RegisterWindowClass() if you plan to be changing the cursor constantly (see MSDN on SetCursor() ).

Of course, there’s a few problems with keeping this functionality platform-independant, since I think X and Win32 want icons/cursors in different formats. GLFW would be left with picking a common denominator, and converting as needed.

Any discussion on this topic would be appreciated.


cozman wrote on Friday, July 01, 2005:

This is very well put. Is anybody currently working on the cursor support for X? I don’t know how to do it, but if nobody is working on it I’d be willing to do the research (shouldn’t be too hard I assume) and give it a shot.

melekor wrote on Sunday, July 03, 2005:

Thanks for showing some support for my idea Wesley. I already have the win32 code done, so I guess it’s up to Marcus now to make this happen officially. Until then, you can get my source code from