[speps]

It's what they describe though. You can use QRhi to write code that works on all platforms, it's low level enough already. ANGLE is redundant in this case and that's why it's gone. You don't need to write it for Metal or DX11, it'll map the RHI calls correctly and recompile SPIR-V to DXBC for example.

[leiserfg]

True, but if you are porting an OpenGl App (like Krita) you'll need to rewrite all your "hardware accelerated code" from scratch with maybe zero gain.

[divingdragon]

It appears that one might not even be able to make use of QRhi without porting all the QWidget-based UI over to Qt Quick.

Given how some high-profile Qt applications are using OpenGL, continuing with using ANGLE would seem to be the superior choice over having to rewrite everything with a completely new API.

[jcelerier]

I use QRhi for the shader pipeline in https://ossia.io which is a QWidget desktop app

[divingdragon]

Just curious: Is it possible to do rendering with QRhi inside QWidget in a similar way as one would do with QOpenGLWidget?

Actually, the post also stated that using `QQuickWidget` will force OpenGL composition, so if an application uses QML inside QWidget it looks like QRhi will not be usable at all. It would seem that QWidget composition does not support QRhi.

[jcelerier]

It works fine with QWidget::createWindowContainer on the QRhi viewport here : https://jeanmichael-gmail.tinytake.com/tt/NDc3MjgxOF8xNTA4MT...

top is your most classic QTreeView, bottom is the widget with content rendered through RHI (a preview of a shader effect)

[divingdragon]

Ah right, createWindowContainer should work for this.

I believe there is a reason why we don't call createWindowContainer with our use of QOpenGLWidget, though I currently can't remember it. If it still applies, then I suppose we might not be able to use QRhi.

[boudewijnrempt]

Well... It's possible to use QRhi, but the blogpost explicitly says that QRhi is private and "QRhi or the new shader pipeline plays no role here at the moment, in Qt 6.0 at least. "