Wayland Protocols 1.30 Introduces New Protocol To Allow Screen Tearing
In the early days of Wayland one of the main philosophical driving points for this alternative to the X.Org Server was that "every frame is perfect" and would forego screen tearing among other rendering impurities. Introduced now with Wayland Protocols 1.30 though is a new staging protocol to allow screen tearing.
Wayland Protocols 1.30 was released today where the sole change is a new staging protocol to allow optional tearing. The new tearing control protocol allows clients to let the compositors know that their surface's contents can "tear" if necessary -- showing a mix of old/new surface contents.
The intent with this tearing control protocol is for latency-sensitive software like games and graphics drawing tablet programs to tear if needed in order to reduce the input to screen latency.
Clients can use the tearing-control protocol to indicate they are fine with tearing via async page-flipping. The tearing_control_v1 protocol has been worked on since last year by KDE developer Xaver Hugl.
The new tearing_control_v1 specification sums itself up as:
Wayland Protocols 1.30 was released today where the sole change is a new staging protocol to allow optional tearing. The new tearing control protocol allows clients to let the compositors know that their surface's contents can "tear" if necessary -- showing a mix of old/new surface contents.
The intent with this tearing control protocol is for latency-sensitive software like games and graphics drawing tablet programs to tear if needed in order to reduce the input to screen latency.
Clients can use the tearing-control protocol to indicate they are fine with tearing via async page-flipping. The tearing_control_v1 protocol has been worked on since last year by KDE developer Xaver Hugl.
The new tearing_control_v1 specification sums itself up as:
For some use cases like games or drawing tablets it can make sense to reduce latency by accepting tearing with the use of asynchronous page flips. This global is a factory interface, allowing clients to inform which type of presentation the content of their surfaces is suitable for.The goal, of course, is to achieve no screen tearing and by default this protocol doesn't change the client behavior or intended Wayland compositor behavior around screen tearing.
Graphics APIs like EGL or Vulkan, that manage the buffer queue and commits of a wl_surface themselves, are likely to be using this extension internally. If a client is using such an API for a wl_surface, it should not directly use this extension on that surface, to avoid raising a tearing_control_exists protocol error.
123 Comments