Hello I have some 3d stuff in my editor that can be dragged(translated) around (with mouse). I update on change only (no renderloop) so I handle this on WM_MOUSEMOVE case WM_MOUSEMOVE { GetCursorPos(m) TranlateStuffToM (m) Render () Swap () } rendering takes some time, and I see that after swap, the cursor may already be somewhere else. So I figure to render first, then check if the mouse is still there, if so, then swap (make it visible). otherwise, dont swap, cause it shouldnt be visible there anymore. though it seems the swapping takes all the time, so I cant get it truly/consistently up to date. any thoughts on this (in general) ?? (rendering faster/vbos or something might help, but dont really solve this also I think) thanx

Disable VSync if you haven't already.

Quote:Original post by Erik Rufelt
Disable VSync if you haven't already.

disabling vsync makes it just a little better in terms of speed, but doesnt solve it.

Quote:Original post by NisseBosseLasse
Why are you calling GetCursorPos? The coordinates are stored in lParam.

i know, thought this would be a bit clearer. anyhow, its hardly the point..
(to be exact, client coordinates are stored in lParam, and this is not the clientsystem that Im working in (im in a child frame space). Whereas GetCursorPos retrieves screenspace coords.)

Hide the windows cursor and draw your own with OpenGL instead, and enable vsync again. That will give you perfection as long as your framerate is high enough to not miss any vsync. If your framerate is not high enough then it can't be solved.
It can not be solved 100% when drawing in WM_MOUSEMOVE, since it will always depend on if you're lucky and happens to receive that message right away and not have any delays from other messages or whatever. Try logging every WM_MOUSEMOVE message to file with timestamps and drag the cursor around a bit, it's not a perfect update.
The exact same problem is seen when dragging windows or icons or images, and even in games that use the windows cursor if the computer is too slow. The cursor redraw is not synchronized to OpenGL and you will most probably always be a couple of frames behind. It's supposed to be that way, since the driver often caches 3 frames ahead to avoid missing vsync.

drawing the mouse in gl really isnt an option for me.
I guess ill just let it slide :)
thanx