Does Reactive Update Mode use the platform's blocking message fetcher?

[expikr]

Specifically, on Windows there is PeekMessage() and GetMessage().

I am relying on using the latter to obtain precise timestamps of when the OS unblocks the function by making a QueryPerformanceCounter call as the very first thing that the message loop does upon returning.

Pretty much the majority of game engine or frameworks like SDL2 provides a "fake" wait_message equivalent, where they simply use the polling counterpart instead with a cooldown, purely for the purpose of "saving power".

For my purpose, however, I need the blocking behaviour not to save power but to characterize precise timestamps. Does Bevy's reactive update mode use the "real" message fetcher? If so, how may I be able to insert the timestamping action as the very first thing it does after returning? I would like to have the events dispatched by Bevy to have these accurate timestamps available.

They need to be implement in the message loop directly, otherwise the whole purpose is lost if I simply add in a timestamper after it has already been processed and forwarded by Bevy

---

On an entirely unrelated note, I would also like to have the GetMessagePos() information available for my incoming messages forwarded by Bevy. Also the mouse motion events seems to only include the deltaX/Y data, there don't seem to be any way to query the device handle that sent those individual raw device reports?

[aevyrie]

For my purpose, however, I need the blocking behaviour not to save power but to characterize precise timestamps. Does Bevy's reactive update mode use the "real" message fetcher? If so, how may I be able to insert the timestamping action as the very first thing it does after returning? I would like to have the events dispatched by Bevy to have these accurate timestamps available.

Can you provide more details about this? I don't follow. I might be missing the requisite knowledge to understand the question.

All the reactive mode does is tell winit to wait until an event is received before running the next frame. If event(s) have been received since the last frame was started, the loop will run immediately and report the list of events received since last time.

If I understand what you are requesting, you probably want to run your app in continuous mode, and block the main thread with spin_sleep if needed. You can put this system in the CoreStage::First stage to make sure it runs first. Alternatively, you can define your own runner if you need even more control: https://github.com/bevyengine/bevy/blob/main/examples/app/custom_loop.rs

[expikr]

More specific description of my requirement:

From https://docs.microsoft.com/en-us/windows/win32/winmsg/using-messages-and-message-queues

You can use the PeekMessage function to examine a message queue during a lengthy operation. PeekMessage is similar to the GetMessage function; both check a message queue for a message that matches the filter criteria and then copy the message to an MSG structure. The main difference between the two functions is that GetMessage does not return until a message matching the filter criteria is placed in the queue, whereas PeekMessage returns immediately regardless of whether a message is in the queue.

I'm using the fact that the return timing of GetMessage returns at the precise instant the OS queues the message, if the queue is normally empty. This lets me characterize most exact timestamp that is physically achievable on the Operating System. Specifically I'm trying to profile the jitter/variance aspect of the OS itself

[tim-blackbird]

I wonder what your use-case for this is in a Bevy app?

But, since winit does not expose raw, os-specific events like this, I'm afraid you'll have to do this on your own.

[expikr]

I imagined so, in which case the question is then how might I be able to integrate my own lightweight messageloop proxy into the rest of Bevy keeping most of its structure intact? Ideally just hooking in specific message types and forward them to Bevy, where Bevy would treat it as if it's directly coming from the OS

My use case is benchmarking timing jitter of OS input processing. Only the lightweight timestamping is timing-critical, the visualization is just a presentation of the timestamped data over time.