Native Qt QML Fullscreen application

[Zack]

I would like to now, whether it is possible to create a native fullscreen application with QML?
I know there is the "fake fullscreen" approach, with maximizing the window to screen coordinates.
However, this is not real native fullscreen.

With native I mean, that you can set a custom resolution to the monitor and then QML renders into it.
I asking because there is a performance difference, between rendering in native fullscreen widget or fake fullscreen widgets.
See here for details:
https://www.reddit.com/r/pcgaming/comments/5gz5wc/what_is_the_difference_between_fullscreen_and/

[J.Hilk]

@Zack
I don't think its possible to change the OS screen resolution with an qt-api, Youll have to call plattform specific code.

For Windows, take a look here:
https://msdn.microsoft.com/en-us/library/dd183411(v=vs.85).aspx

[timday]

Curious why you'd want to do this these days. Back in the days when CRT monitors were the norm it was common enough (together with ghastly flickering and curious clicking noises from the monitor as the mode was changed)... but now in my experience most LCD displays look absolutely terrible if you drive them at anything other than their native resolution.

If for performance reasons you want to render a (say) 960x540 window instead of a display resolution 1920x1080, better to render at that resolution then scale up at the final step using a shader effect maybe (at that point you have a chance to apply an adaptive sharpening filter to try and hide the fact you're rendering at lower resolution).

[Zack]

I need to render some output from a camera in fullscreen as fast as possible.
My internal tests has shown that when rendering with native directX and its done in fullscreen I get a latency of 65ms, when using windowed mode I get a latency of 75ms.
Using QML I am arround 80ms, so I have asked my self whether I can drop the latency, whith using native fullscreen.

[timday]

Interesting problem... I had a project which worried about that sort of stuff back in the days of AGP graphics cards... (back then we found transfers to/from a GPU card could be done significantly faster using DirectDraw than by using Direct3D or GDI APIs. Think DirectDraw has been deprecated since though, and the Windows driver model is all changed now).

One thought... the difference between your best 65ms and QML's 80ms is suspiciously close to 16ms and (probably) your monitor's 60Hz refresh rate. Suggests there could be an extra vsync delay getting in there or something. Might be interesting to see if messing with QSurfaceFormat::SwapBehavior (via QWindow::setFormat) changes anything (and/or setting QSurfaceFormat::setSwapInterval to zero... not sure how the two interact.