I just hope they bring back angle as a cross platform back-end so you can access "low level graphic hardware" without needing to implement also for Metal and Directx11.
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.
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.
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.
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.
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. "