hardware cursor using OpenGL

[Johnson.N.M.B]

Hi, is it possible to enable hardware cursor in opengl like D3D does?

[Korval]

OpenGL has no concept of a "hardware cursor".

Further, on a more personal note, I would suggest trying to avoid such things. After all, rendering the cursor yourself gives you control over it.

[Johnson.N.M.B]

Ok, I'm now using a software cursor in my project when OpenGL renderer has been selected. I found it is useful to have a smoothly mouse cursor movement when the FPS is low. I'll try using a true-color windows cursor instead.

Thanks~

[sqrt[-1]]

It is possible to have a hardware cursor with OpenGL. Many previous projects of mine used this - however I don't have access to the code that does this (win32 stuff) so I can't help you further.

[speedy]

sqrt[-1]: You mean some OpenGL hack or just using the standard win32 built-in cursor routines?

[songho]

I am confused.
Should the cursor be always visible, unless you force to hide it explicitly?

And, I think that the hardware cursor means flicker-free. (A video card draws the cursor onto the frame right before the frame is rendered.) If we use double buffer and draw own cursor image, then it should not be flickered.

[sqrt[-1]]

I did not do the code myself, so I cannot say for sure. But I am reasonably certain it was just win32 calls. (just showcursor calls? perhaps it was the initial screen creation - perhaps they created a full screen boarderless window?)

[dorbie]

The HW cursor works with OpenGL, and should be flicker free, you have to explicitly disable it to hide it (you can specify this in the window creation structure I think). You can also draw your own cursor of course but you need to make sure you disable the HW cursor if you do that.

I think you need to post more details.

[tamlin]

If we're talking about the mouse cursor, and fullscreen, I just wanted to share a little something I encountered porting a D3D game to OpenGL.

Profiling the app told me that drawing the cursor was a horrible performance hog. I fixed in just a few lines of code (though the same fix applies to D3D too).

After the UI (2D, though using 3D primitives) was rendered, the code did a color-key "blit". Imagine the pipeline stalls and (lack of) readback speed on slower busses. I did the only obvious thing; I uploaded the mouse cursor image to a texture and after the rest of the UI was rendered I slapped it onto a quad (in ortho mode). I'm not exaggerating when I say that this single change increased UI performance more than 5 times of the whole UI drawing (it has since improved a little more, from 15-30 fps to >2000 fps before adding sanity-Sleep()'ing).

I think this displays it can be better to first try to solve the "problem" within the environment (OpenGL) when possible, not to mention the performance benefits can be... large.

[V-man]

Originally posted by tamlin:
I'm not exaggerating when I say that this single change increased UI performance more than 5 times of the whole UI drawing (it has since improved a little more, from 15-30 fps to >2000 fps before adding sanity-Sleep()'ing).

5 times the speed sounds ridiculous to me. You mean you hid the standard mouse with ShowCursor?
So 30 * 5 = 150 FPS

You added Sleep sometime afterwards and your FPS went to 2000? Again, sounds weird.

What graphics card is this and what driver, what OS?