Details
-
Task
-
Resolution: Unresolved
-
P3: Somewhat important
-
None
-
None
-
None
Description
We don't have a good stategy to handle the case of a QWindow being created with a surface type the underlying platform can't support.
In many cases we end up with a QPlatformWindow, with a native surface type (CAlayer on macOS), that doesn't match the requested surface type, which breaks assumptions further down the line in Qt.
We could solve this by reconfiguring the surface type when creation fails, so that the QWindow reports a different surface type after creation than what was requested.
Another strategey is to return null from createPlatformWindow(), so that the QWIndow handle() returns nullptr, reflecting the failure to create.
In both cases the client code needs to account for the possibility of surfaceType() not matching the request, or the handle() returning nullptr.
If we have other cases where creation can fail it might be best to generalize it to return nullptr, instead of forcing the user to check all the QWindow properties to see if they match what it initially asked (and having to store that locally before creation).
Also, falling back to an alternative format automatically might not match the users preferred fallback. Ie Meta -> Raster, but the user wants Metal -> OpenGL.
For the window's surface format, we have requestedFormat and format(), the latter returning the actual format after creation.