CODEWITHSUNDEEP
c++winapiopenglmouse
John Bananas
John Bananas

Reputation: 821

Missing mouse movement messages in Win32

I'm writing a Win32 OpenGL application for painting where it is critical that all mouse movement is handled. As it happens, sometimes the painting operation in my program is not able to perform in real time -- which is fine for me, as long as all mouse events are queued and can be handled later. Now I would have thought that this would simply be a matter of calling PeekMessage making sure to process all events, but when I do this, it is apparent that the mouse movements my application receives are not of the same fidelity that as those being displayed by Windows.

Is this a feature of Windows? Are mouse event dropped when the application is labor intensive? Or am I missing something? In either case, what can I do to remedy this situation? I would like to avoid multi-threading, part of the reason being that, as I understand, Win32 requires the message callback to be in the main thread and I'm not sure about separating the OpenGL-stuff to a different context.

And as for code example, I am essentially using the template code in the link below. The message I'm checking for is WM_MOUSEMOVE.

http://nehe.gamedev.net/tutorial/creating_an_opengl_window_(win32)/13001/

Upvotes: 3

Views: 2451

Answers (2)

jamesdlin
jamesdlin

Reputation: 90095

WM_MOUSEMOVE is special in that it isn't queued; it's automatically generated as needed when the message queue is empty. (WM_PAINT and WM_TIMER behave the same way.)

Raymond Chen suggests using GetMouseMovePointsEx if you need additional mouse input data.

Additional reading:

Upvotes: 7

Hans Passant
Hans Passant

Reputation: 941990

Is this a feature of Windows? Are mouse event dropped when the application is labor intensive?

Yes, this is a feature. WM_MOUSEMOVE messages are not dropped, they are synthesized. In other words, they are not actually posted to the message queue. That wouldn't work very well in practice, a user could generate a great many mouse moves in a second and rapidly fill the message queue to capacity when your program is busy.

You get a WM_MOUSEMOVE message when the mouse was moved since the last time you called GetMessage(). And you get the last known position. So the rate at which you get them, and the number of pixels between them, depend directly on how often you call GetMessage().

An alternative is to use raw input.

Upvotes: 7

Related Questions