Introduction
How does ParaView work with Wayland and how will it work in the future ?
Wayland 1 is a windowing protocol and is implemented in the Weston compositor, but others exist. Wayland is designed as a replacement for Xorg and many libs provided by Xlib.
ParaView obviously needs to use a Windowing system in order to create the different window that the user can interact with, either through Qt or directly for offscreen rendering.
ParaView is currently using the Xlib API, even when being run on a Wayland system.
Current status
ParaView 6.0 and all versions before that uses the Xlib API to create and interact with windows, either through Qt or directly through VTK implementation.
It works on Wayland systems thanks to XWayland 2.
XWayland is a lightweight Xorg server implementation that communicates with Wayland and provides compatibility between applications using Xorg and Wayland.
It can simply be installed on any linux distributions using the package manager 3.
It notably has similar or better performance compared to using Xorg directly, so using Wayland with Xorg applications may already be beneficial 4.
However, some users report instability with the nvidia drivers 5 and some advanced usages of Xorg may not work as expected with XWayland.
Future work
While XWayland is nice for the transition phase, ParaView cannot rely on it indefinitely and many developments will need to be implemented in order to support Wayland properly.
EGL compatibility
Before being able to use Wayland, being able to render into an EGL window is needed 6. EGL is a compatibility layer between the rendering API and the actual windowing system. It can be used without any graphical environment, with Xorg and with Wayland, the latter relies on EGL for window creation.
ParaView is already able to use EGL to create offscreen windows in order to render images on a system without a graphical environment but does not support rendering into onscreen (aka visible) EGL windows.
Adding the possibility of creating onscreen windows with EGL in VTK is absolutely necessary before considering properly supporting Wayland.
This is a currently ongoing effort and we expect this support to be added in VTK v9.6.0 / ParaView v6.1.0
However, being able to render is only a part of what is needed, as the window is also responsible for transmitting interaction events from the user, which is called an “interactor”.
It will be needed to add an EGL interactor in VTK before considering supporting Wayland.
Wayland switch
Once EGL is supported for rendering and interaction, it becomes possible to use Wayland instead of Xorg. It will require some CMake and Qt work 7 to make it possible. However, it will require a lot of CI work to ensure this is well tested and early testing shows possible artifacts issues to fix.
WebGPU
In the future, VTK and ParaView will rely on WebGPU for rendering, this may imply some rework of the EGL stack, however that work should be pretty straightforward once VTK modules are adapted for it.
This analysis was performed using the resources provided and supported by EDF
