search

opentk / GLWpfControl

A fast native control for OpenTK 4.x + 3.x on WPF.
MIT License
187 stars 46 forks source link

Turning off vertical sync doesn't have any effect #63

Open hanspacket opened 2 years ago

hanspacket commented 2 years ago

During some prototyping work, I wanted to compare the performance of GLWpfControl with my current approach for rendering OpenGL content in WPF. I would basically like to measure which approach has the biggest performance overhead. My intent is to open a large window, and compare framerates for both approaches. I don't want to add too much actual content so that the performance overhead is more prominent, so I'm painting a fairly lightweight scene using OpenGL.

This means that I end up with high framerates, even for fairly large windows (3840x1080 in my case, I can't seem to go beyond this size). To get proper FPS results, I disabled Vertical Sync in the NVidia control panel. This has the following effect:

The second point is a bit unexpected for me since I didn't see anything in the GLWpfControl source code that indicates a fixed framerate. I might be wrong though.

Is this a bug ? Is this a normal side-effect of the DirectX-OpenGL interop in GLWpfControl ? Is the framerate capping something I can enable or disable some other way ?

Note that I'm using OpenTK.GLWpfControl version 3.3.0 since I'm using .Net Framework.

NogginBops commented 2 years ago

It does seem weird that the framerate is limited. This might have something to do with the DX-OpenGL interop, but I'm not sure. I'm not sure when I'll be able to look into this, especially the 3.3.0 version but I'll keep it on my todo.

nasser225 commented 1 year ago

Hi @NogginBops , did you get anywhere with this? I am experiencing the same issue - 60FPS limited using GLWpfControl 4.1.0

NogginBops commented 1 year ago

I've not gotten to this issue yet. I'm planning a refactor of the DX interop part of this control and while doing that I can look into what the issue is here with vsync

NogginBops commented 1 month ago

My current guess for this is that WPF is limiting the framerate in their render thread. We are using D3DImage to display DirectX content in WPF and I guess that the refresh rate of that is locked to WPF in some way.