Is QML GPU accelerated by default?

[RokeJulianLockhart]

I haven't been able to locate any relevant information via Google.

[RokeJulianLockhart]

QtQuick used to require a GPU to be present. But now a software renderer which has limitations.

@SGaist, thanks for that. Never would have found that article in a million years. However, I found a comment which appears to summarise both its current state and why I asked this succinctly, if correct:

Yes QtQuick is much much faster in rendering high resolution complex scenes due to leveraging the gpu through the use of QRHI. Its the awesome rendering abstraction Qt made so it will call Dx11 Dx12 Vulkan Metal Opengl depending on the platform you compile for. This ensures you use the best graphics api for the platform as Opengl drivers (from most gpu vendors)on windows sucks compared to DirectX, so much so google even developed ANGLE.

But I hear you say the word ‘responsiveness’ and this is something were a very nasty truth comes to light about QtQuick. By default Qt uses VSync and a swapChain interval of 2 or 3 frames (you can configure this) to throttle the rendering so we are not rendering 7000fps for a screen that can only display 120 per second. This adds latency which is noticable to the user.

Likewise, since I'm asking this in a KDE context, reddit.com/r/kde/comments/81dfdc/comment/dv37xdr is of use:

Today we need to compare QWidget and QtQuick. QWidget is rendered with what raster used to be, so no. QtQuick is by default rendered with OpenGL, so yes.

Though, I presume they mean QtWidgets in the stead of QWidget.

[SGaist]

Hi,

QtQuick used to require a GPU to be present. But now a software renderer which has limitations.

See this Toradex article for example.

[RokeJulianLockhart]

QtQuick used to require a GPU to be present. But now a software renderer which has limitations.

@SGaist, thanks for that. Never would have found that article in a million years. However, I found a comment which appears to summarise both its current state and why I asked this succinctly, if correct:

Yes QtQuick is much much faster in rendering high resolution complex scenes due to leveraging the gpu through the use of QRHI. Its the awesome rendering abstraction Qt made so it will call Dx11 Dx12 Vulkan Metal Opengl depending on the platform you compile for. This ensures you use the best graphics api for the platform as Opengl drivers (from most gpu vendors)on windows sucks compared to DirectX, so much so google even developed ANGLE.

But I hear you say the word ‘responsiveness’ and this is something were a very nasty truth comes to light about QtQuick. By default Qt uses VSync and a swapChain interval of 2 or 3 frames (you can configure this) to throttle the rendering so we are not rendering 7000fps for a screen that can only display 120 per second. This adds latency which is noticable to the user.

Likewise, since I'm asking this in a KDE context, reddit.com/r/kde/comments/81dfdc/comment/dv37xdr is of use:

Today we need to compare QWidget and QtQuick. QWidget is rendered with what raster used to be, so no. QtQuick is by default rendered with OpenGL, so yes.

Though, I presume they mean QtWidgets in the stead of QWidget.