Ability to change present mode on the fly
opened this issue · comments
Is it possible to change present modes on the fly, instead of just at initialization? I'm building a game framework with skulpin-renderer and it would be nice if it was.
An API like this could work. (a way to get a list of available present modes is nice too).
let mut renderer = ...;
renderer.try_set_present_mode(PresentMode::Immediate)?;
Hello, sorry I forgot to reply! I'm actually wanting to reduce the API that's exposed.. there is a preview in this branch: https://github.com/aclysma/skulpin/tree/use-rafx
This change will actually remove present mode entirely. It's certainly possible to expose it and if you're willing to destroy/recreate the swap chain, it would be possible to change the present mode. However, I think you'd need to write your own renderer that uses skulpin. (But it will take a lot less code with the changes in that branch to do it, and you'll get a lot more flexibility).
Would you mind explaining why you want to set the present mode at runtime? Generally speaking the choice is mostly about if you want to reduce latency (games) or improve battery life (a productivity application like neovide), so I'm curious what you have in mind. :)
I should add, part of the reason I want to reduce the API is so that I can add support for metal or other graphics backends. PresentMode is a concept that AFAIK only exists in Vulkan and I'd rather not expose backend-specific APIs unless there is a really good reason to do it.
I didn't actually mean to be able to pick a specific Vulkan present mode, sorry. The request was purely so I can enable/disable immediate drawing at runtime. In Vulkan, that would be switching between Immediate and Mailbox, hence the original opening of this issue.
The motivation for me to request such functionality is because I'm building a rhythm game. Such games are best with immediate drawing to reduce latency, but IMO a switch for disabling that would be convenient if one wanted to run the game on a battery-powered device.
If there is a similar "enable/disable VSync" in Metal, OpenGL or other Skia backends you want to support, then I think the request is not far-fetched.
Ah ok, that makes sense. Vsync enabled/disabled is a good level of abstraction and is broadly supported across graphics APIs. This is just a matter of passing a bool when building the swapchain so changing it at runtime will require rebuilding the swapchain.
Also, this may be a bit off-topic, but do you plan on supporting OpenGL alongside Vulkan & Metal in Rafx for compatibility with older hardware?
I’m definitely thinking about it. Likely it would be ES 2.0 to support WebGL. WebGL2 is not supported on Apple devices and webgpu is not natively supported/enabled by default in any browser AFAIK. A gl backend would not have feature parity with other backends because of API limitations. I’m not sure when I’ll get around to it. The list of things I want to do is pretty long! :)