[WebXR] Add support for getting and setting display refresh rate

[dsnopek]

This is currently a draft because it's completely untested - I just whipped it up because @Malcolmnixon asked about it :-)

This is fully working and tested now!

Also, this in NOT essential for 4.0 at all, it can wait until later :-)

[BastiaanOlij]

Looks like a good start! Did you find out if WebXR has the same issue as the Quest native where it defaults to Quest 1s 72hz refresh rate but reports 90hz?

[dsnopek]

I've finally had a chance to test this, and it basically works! However, it's a little counter-intuitive.

It'll report a refresh rate of 0 until it has been explicitly set to some value. And, like all things in WebXR, it's asynchronous, so the change won't happen immediately, but some time later (after 1 or more frames; or never, if it fails). But once it has successfully changed, then it'll start reporting the actual refresh rate.

So, probably the right way to use it, is to call get_available_display_refresh_rates() right after the WebXR session starts, pick one that's closest to your desired frame rate, and then set it right away.

Because it's asynchronous, I've added a signal (display_refresh_rate_changed) so the game developer will know when to make any changes for the new frame rate, like, for example, setting the physics tick rate to match the refresh rate.

For this same reason, I'm thinking about removing the display_refresh_rate property, and just having the getter and setter methods. It's really weird to set a property to a value, but have it report a different value when you get it. (And since the requested change might actually fail, we probably shouldn't fake it with a local variable.)

Did you find out if WebXR has the same issue as the Quest native where it defaults to Quest 1s 72hz refresh rate but reports 90hz?

I guess not, because it always reports 0 until it's changed :-)

[Malcolmnixon]

This is roughly on par with the OpenXR experience - In the frame-rate control (GodotVR/godot-xr-tools#364) we handled the odd behavior.

I figure we'll extend the same file to handle refresh rate for WebXR in exactly the same way:

1. Let the user pick a desired refresh rate (or use the reported rate if not specified)
2. Set the refresh rate to the supported rate closest to the desired
3. Assume the refresh rate change will go through and set the physics rate appropriately

For OpenXR/Quest we get the oddity of it reporting 90hz while running at 72hz; so if the user doesn't request a desired rate we pick 90hz (closest to the bogus 90 reported). Given the rules above, for WebXR/Quest if the user doesn't request a desired rate we would end up picking 72Hz (closest to the bogus 0 reported).

[dsnopek]

Given the rules above, for WebXR/Quest if the user doesn't request a desired rate we would end up picking 72Hz (closest to the bogus 0 reported).

Hm, the lowest it reports supporting is 60, so if it's going to grab the lowest one, it would end up on 60 which isn't ideal.

In any case, that's not something we need to solve here :-)

[dsnopek]

I've removed the WebXRInterface.display_refresh_rate property in favor of the getter and setter methods, since setting the value is asynchronous (and may not succeed).

At this point, this functionality is working and ready for review, so I'm taking it out of draft!

[dsnopek]

Now that we're past the 4.0 stable release, this PR's time has come! :-)

@BastiaanOlij @m4gr3d @Malcolmnixon Can one of you review this PR when you have a chance? Thanks!

[Malcolmnixon]

This looks good to me, and testing showed it works fine on my Quest 2 in WebXR.

[akien-mga]

Thanks!