QtWayland Remaining Issues

From Qt Wiki
Jump to navigation Jump to search
  • 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