QtWayland Remaining Issues

• Wayland has fixed concepts and Qt has its own and they dont match
• For instance positioning of popups: tooltips, comboboxes, menus, and basically any QWindow which can be a transient child of another window
• The client doesnt know where the screen is and the compositor doesnt know how to adapt, it doesnt have the semantic information
• In Wayland there is semantic positioning, anchoring, adapting to available real estate
• Information is in Qt, but not available through QPA
• There is a patch, but it is scary because many platforms are affected
• Could introduce the new thing first for Wayland only and keep the old and gradually migrate
• Public APIs may also be affected
• Could it be done in QPA first with no public
• Not sure this should have public API: Only relevant for tooltips, which has an anchor rect already, so maybe its covered
• We dont need public API for the fallback logic
• Platform header additions needed because different types of popups need different behavior
• PopupWindowPositioningDescriptorHelper?
• Fallback logic should be something the QPA plugin decides based on the type of popup
• In a RTL language, the semantics may be flipped. We know the directionality of the locale language, but not necessarily of the language in the combobox
• Go more semantic: Don't provide instructions, but give a rectangle and information about what it means

• Other thing: In Wayland setting properties/state for a surface is atomic, which gets in trouble with a render thread which may be rendering into and comitting a buffer with the old size
• On NVIDIA drivers, you can run into a crash bug which is probably a driver bug
• On very strict compositor, they can refuse to render your window because it detects a non-compliant client
• Resizing synchronization is a problem we have on all platforms actually
• Can we delay the reply? The problem is that we can't detect on the main thread
• Can we throw away the frame if the size changed? That has been done on other platforms but also causes some problems
• RHI has beginFrame/endFrame which might be useable, but we cant depend on those being called in a custom renderer
• Another case: When you move a window with an item anchored to it, then it will lag behind now, but it should be exact
• We need a follow-up meeting in January with relevant people to find a solution to the general cross-platform problem of resizing while rendering is happening
• For the crash on NVIDIA we will look into hotfixing this with beginFrame/endFrame, which could be temporary if we find a general solution