Support 120 fps for Win32RenderingMode.Wgl about avalonia HOT 7 OPEN

Related #14073 (comment)

from avalonia.

Currently, Win32Platform is hardcoded to run at 60fps here:

It's not. It uses display VSync by default, where you can't change framerate, it can go far higher than 60fps normally. You can disable it in CompositionMode option, but it's not advised.
Adding FPS option might be confusing, as changing its value won't affect majority of Avalonia apps.

60 is only forced when other render timers are used, like a fallback for older systems or when ShouldRenderOnUIThread is used.

LinuxFramebufferPlatform currently supports customizable FPS:

Framebuffer doesn't have any vsync, so that's the only option there, yes.

from avalonia.

Currently, Win32Platform is hardcoded to run at 60fps here:

It's not. It uses display VSync by default, where you can't change framerate, it can go far higher than 60fps normally. You can disable it in CompositionMode option, but it's not advised. Adding FPS option might be confusing, as changing its value won't affect majority of Avalonia apps.

60 is only forced when other render timers are used, like a fallback for older systems or when ShouldRenderOnUIThread is used.

LinuxFramebufferPlatform currently supports customizable FPS:

Framebuffer doesn't have any vsync, so that's the only option there, yes.

Ah, thanks for the clarification!

Based on my experience, it really did feel like Avalonia was locked at 60 fps, since even the smallest possible OpenGL app (i.e. just clearing the screen) would only run at 60 fps. However, I tried out the Avalonia sample projects and noticed those were indeed running at 120 fps.

I've narrowed down the issue I was seeing to the following code in the AppBuilder:

.With(new Win32PlatformOptions {
    RenderingMode = [Win32RenderingMode.Wgl],
})

When the RenderingMode is set to Win32RenderingMode.Wgl, the highest my app can go is 60 fps; when this is removed, it can go up to 120 fps. It looks like you mentioned this in a different issue actually, I just hadn't noticed that when I was first investigating this.
#13125 (reply in thread)

from avalonia.

Yeah, you are correct. Wgl won't support CompositionMode vsync. We might need to use wglSwapIntervalEXT in order to support similar behavior there. If not, it's better to add FPS config selector to new WglOptions class or similar and not common Win32PlatformOptions.

Btw, why do you need WGL? Normally, we don't recommend it, unless it's necessary for your dependencies.

from avalonia.

Ah, sounds good! Yes, it doesn't necessarily need to be in Win32PlatformOptions, just wherever would be best for Avalonia in the long term.

I need Wgl because my Avalonia app uses OpenTK to render a 3D view, I've hooked into Avalonia's OpenGL logic using an approach similar to this library:
https://github.com/SamboyCoding/OpenTKAvalonia

Any other Win32RenderingMode results in memory access violations when starting the app; the README for the above project states this is due to the following:

Note that, in order for events to be called on Windows, Avalonia must be able to load the OpenGL bindings, which requires switching the default rendering mode.

Without this, your control simply will never receive any of the OpenTK events (Initialization, Teardown, and Render).

from avalonia.

Note that, in order for events to be called on Windows, Avalonia must be able to load the OpenGL bindings, which requires switching the default rendering mode.

Is it still true with Angle OpenGL though, which is default? Normal OpenGlControlBase works there just fine.

from avalonia.

WGL isn't really supported as the primary backend. If you need to present non-ANGLE OpenGL rendering, use WGL_NV_DX_interop2, ID3D11Texture and #9925

from avalonia.