SwapChainRendering issue

[SuperYF-86]

Hi.

I have a question about enabling SwapChainRendering.

I have created a very simple WPF application to test it, here is my code.

The rendering frame rate in this project with SwapChainRendering enabled is significantly lower than in D3D mode. And the maximum frame rate seems to be locked at 65FPS.

But the interesting thing is that once I turned on ContinuousRender3D, SwapChain mode could achieve a frame rate similar to D3D.

Finally when I disabled D3D Viewport, the maximum frame rate of SwapChain Viewport went back to 65FPS.

I found this problem purely coincidental. Using SwapChain mode in another project of mine was not locked to 65FPS and the overall performance was significantly better than D3D, especially when rendering a large number of elements.

This is very strange, except for that project. All of my test results have SwapChain mode locked at 65FPS, and I can clearly feel the lag when dragging the viewport.

Has anyone else had a similar problem? How do you guys usually enable SwapChainRendering?

[holance]

This is because render thread is controlled by wpf compositionTarget rendering thread. WPF rendering thread adjusts its frame rate dynamically based on its content updating rate.

Helixtoolkit uses lazy rendering, which means it only triggers rendering when things get changed. When you are using ContinuousRender3D, Helixtoolkit will render new image for each frame triggered by compositionTarget, and compositionTarget will try to run its full speed all the time.

However, swapchain update is unable to be detected by wpf rendering thread because it is running on winform host, which provides a native window pointer to the swapchain during creation. So the wpf rendering thread is just running at idling mode instead of full speed. Swapchain framerate is also controlled by vsync, probably that's why there is some frame rate differences.

I would suggest migrating to the new WinUI platform if your project is still at early stage, which provides swapchain support natively for better performance.

[SuperYF-86]

This is because render thread is controlled by wpf compositionTarget rendering thread. WPF rendering thread adjusts its frame rate dynamically based on its content updating rate.

Helixtoolkit uses lazy rendering, which means it only triggers rendering when things get changed. When you are using ContinuousRender3D, Helixtoolkit will render new image for each frame triggered by compositionTarget, and compositionTarget will try to run its full speed all the time.

However, swapchain update is unable to be detected by wpf rendering thread because it is running on winform host, which provides a native window pointer to the swapchain during creation. So the wpf rendering thread is just running at idling mode instead of full speed. Swapchain framerate is also controlled by vsync, probably that's why there is some frame rate differences.

I would suggest migrating to the new WinUI platform if your project is still at early stage, which provides swapchain support natively for better performance.

So that's it!

It's possible that my previous project had a wpf control that contained a looping animation that kept the MainWindow in an "active" state, thus indirectly driving the SwapChain viewport update.

Thank you very much for your reply. I will also consider your suggestion of using WinUI.

[SuperYF-86]

@holance hi, I tried the ModelViewerDemo of WInUI version 2.22.0 on your suggestion.

But the maximum frame rate of the WInUI version of Viewport is only 30fps, while the UWP and WPF versions can reach 165fps. am I missing something?

[holance]

Seems to be a bug in WinUI currently. It only happens if your monitor FPS is more than 60Hz. https://github.com/microsoft/microsoft-ui-xaml/issues/7290

[holance]

Put out a PR to bump up FPS under SharpDX.WPF with swapchain enabled.

[SuperYF-86]

@holance

Thank you very much for the information.

I noticed that with the introduction of WinUI3 this issue seems to have been around for a long time and Microsoft has shown no interest in explaining it so far, so much so that I'm starting to realize that WinUI3 could possibly be designed separately for 60hz displays.

In any case I will give up using WinUI3 for now because it has a lot of unpredictable risks and other problems.

Of course, HelixSharpDX performs very well on WPF and Winform. I will be glad to see it continue to evolve and do better.