Use-cases

Use-case #1: Compositing

When a UI stack determines that more than one graphics stack is in use (GL widget in widget app e.g.), the UI stack (QWidget/QWidgetRepaintManager) needs to explicitly handle the case, typically by compositing the two rendering stacks. This requires explicit support in the UI stack, where the UI stack chooses one of the graphics stacks to do the final rendering, and represents the other graphic stacks in terms of the main one.

In other words: There is no implicit support for merging graphics stacks. Ie, a QBackingStore::flush() can not be used with a QOpenGLContext::swapBuffers() and just magically expected to work.

Use-case #2: Delegation

On some platforms one graphic stack may be implemented in terms of another. For example, on iOS today we implement QBackingStore flush using OpenGL. In the future we may do the same using Metal, even on macOS. Or, on macOS today we implement QVulkanWindow in terms of Metal, since we rely on MoltenVK.

In practice this means that we're interpreting the QWindow surface type not as a one-to-one mapping to an actual graphics technology, but use it as a hint about what Qt graphics stack the user is going to use. In effect, the user ends up with a RasterSurface QWindow, where the underlying NSView or UIView has a OpenGL or Metal layer. Or a VulkanSurface window, with a Metal layer.

Problems

1. We should consider reflecting this back to the user in some way.

This is important for example so that the compositor case can reliably determine if it needs to recreate the window with a new effective surface type.

• By updating the QWindow's surfaceType after create()
  • We already do this to some degree, by updating RasterSurface to RastetGLSurface
• By introducing QPlatformWindow::surfaceType()

Existing code in Qt in various places check the QWindow surfaceType explicitly

• QBackingStore checks  isRasterSurface(QSurface *surface)
• QMetalSwapChain::createOrResize() checks for MetalSurface

2. App has no way to override the platform's choice

Another issue with the current approach is that the app has no way to override the platform's choice in what effective surface type is chosen. Normally you would expect setSurfaceType to be respected, but that means the platform can't influence the choice. Doing so would need some rethinking on default/dynamic surface type (SurfaceType::DefaultSurface/Dynamic/FirstUse), with deferred selection by the platform based on graphics stack being used. 

Since this is not a common use-case we can defer it for now.

QWindow surface type

https://doc-snapshots.qt.io/qt6-dev/qwindow.html#setSurfaceType

Sets the surfaceType of the window.

Specifies whether the window is meant for raster rendering with QBackingStore, or OpenGL rendering with QOpenGLContext.

The surfaceType will be used when the native surface is created in the create() function. Calling this function after the native surface has been created requires calling destroy() and create() to release the old native surface and create a new one.

In other words, the surface type a hint to Qt about which API is going to be used to subsequently render to the surface. As opposed to creating a generic QWindow/QSurface, and then letting the rendering stack configure the surface post-creation.

1. Set surface type to FooSurface
2. Use Qt rendering stack Foo to render to it

Possible regressions

• Wrong source/target rect when winId is used and flushing child QWindows
• Lagging when resizing QWindow on macOS
• Black content under toolbar in richtext example
• No content in Xcode view debugger (Apple/Xcode problem)

Possible improvements/stretch goals

• Not as eager re-eval of config
• Add QRhiBackingstore
• Generic QRhiCompositor, texture-source agnostic
• QBackingStore::scroll