Winit::event_loop tick per second

1

When using winit::event_loop, is there a way to specify how many ticks per second it runs at?

I feel like I am missing something very obvious.

2

I can't answer for other platforms, but most Windows event loops don't tick; they dispatch events whenever they occur. Most events aren't synchronized to frame refresh or to timers.

3

Hmm, so you need a dedicated thread / async-thread to every 1/30th or 1/60th of a second to send it a "redraw" command ?

4

If I was using the raw Win32 API and wasn't using a 3D API (this changes things somewhat), I'd do this:

  • Create a periodic Win32 timer. It posts an event to the message loop
  • While handling the event, request a repaint
  • Win32 creates a draw handle and posts an event which contains that handle
  • Respond to that event by using the draw handle to paint the display

I don't know offhand the winit approach; maybe it's similar?

5

Something is definitely calling redraw, either code I wrote about and forgot or the winit api itself. This is running Rust compiled to wasm32 on Chrome.

6

Try searching the winit sources for requestAnimationFrame(); js uses that for animation loops.

7

Ahhh. See ControlFlow in winit::event_loop - Rust . It defaults to Poll instead of Wait. In native code this goes against typical recommendations for an event loop since it keeps a thread continually spinning (bad for most apps, but good for games). In browsers this uses requestAnimationFrame(), which fires at the browser's refresh rate.

8

I'm not disagreeing with you, but I can't find it in the repo:

 rg requestAnimation -i
CHANGELOG.md
506:- On Web, replaced zero timeout for `ControlFlow::Poll` with `requestAnimationFrame`
9

When using 3D apis, it's generally that which blocks waiting for the next refresh. rAF is a bit different due to the nature of browsers, but it's trying to replicate that behavior, though there's no specification for what that refresh rate exactly is (given different screens it can't, realistically) or any API for getting the intended rate, though Apple at least has used half refresh rate on their 120Hz screens for compatibility with code assuming 60Hz, so that's probably a decent guess.

Trying to target an update rate other than the refresh rate is called frame pacing, and it's really tough to do well if your draws are not much cheaper than a single refresh or you don't have hardware control.

10

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.