Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

update method seems to fire at varied rates. #422

Closed
ELI7VH opened this issue Nov 4, 2019 · 1 comment · Fixed by #452
Closed

update method seems to fire at varied rates. #422

ELI7VH opened this issue Nov 4, 2019 · 1 comment · Fixed by #452

Comments

@ELI7VH
Copy link

ELI7VH commented Nov 4, 2019

I am on a 144hz monitor (MSI GS65) and when my mouse is off the window, it seem to update slower than when my mouse is over the window space.

it seems to happen more than 60 times per second. Is this actually locked to the screen refresh rate?

Is this a known issue? should I be using some kind of delta time?

this happens with all the examples I have loaded as well.

@mitchmindtree
Copy link
Member

Thanks for the issue!

It looks like this is the same issue reported at #307.

Is this actually locked to the screen refresh rate?

Yes that's right, by default the nannou App uses the RefreshSync loop mode which uses the system's FIFO Vulkan present mode for each window's swapchain. The reason for this default is that it's actually the only mode guaranteed to be supported by every platform's swapchain implementation under the Vulkan specification. Normally, there's the option to switch to a fixed rate by switching to the Rate loop mode, e.g.

app.set_loop_mode(LoopMode::rate_fps(60.0));

However, judging by that issue it seems MoltenVK does not yet support this MAILBOX present mode 😱 It may be worth trying this still as it's possible they've implemented the present mode since it was discussed in that issue (I haven't checked). One option for addressing this might be to try to build our own mailbox-style present mode that uses a fixed rate around the FIFO present mode. Alternatively, a better approach might be to wait to address #374 and #408, as after addressing these we would no longer rely on moltenvk and may potentially have access to a proper implementation of MAILBOX through gfx-portability (we'd have to check that gfx supports this to be sure).

should I be using some kind of delta time?

This depends on your use case, but if you find it necessary you can access the delta time through the update: Update argument of the update function, e.g. update.since_last is the duration since the last update and update.since_start is the duration since the app began running.

Hope this helps a bit!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants