[Wayland-bugs] [Bug 98731] EGL client behaviour too undefined

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98731

--- Comment #9 from Pekka Paalanen <ppaalanen at gmail.com> ---
There is one very strict requirement we cannot loosen:

The application MUST be in TOTAL control of when requests to a wl_surface
happen.

This applies specifically to wl_surface.commit, because the application must
know exactly when it latches in the new window state. If the application is not
in total control of commits, it cannot be sure what the window state is, and
therefore it cannot reliably drive the GUI.

This also applies to wl_surface.attach, because the application must be able to
call wl_surface.commit to change the window state irrespective of EGL workings.
If EGL does a wl_surface.attach at arbitrary times, the application may latch
in the buffer without EGL expecting it.

The fundamental assumption made when designing all Wayland protocol extensions
is that the application is in control of wl_surface.commit, and therefore all
extensions that need atomic semantics tie to the wl_surface.commit.

Window state and window content go hand-in-hand, because they need to be kept
in sync. Particularly during window state changes, which usually require a
re-draw, committing the newly drawn buffer must happen in the exact same commit
as latching the new window state. Otherwise the application will be unreliable
and/or glitch visually.

Therefore it is unacceptable for EGL to:
- send wl_surface.attach and/or wl_surface.commit asynchronously
- send wl_surface.attach and/or wl_surface.commit from inside API calls that
have not been defined to do so
- not send wl_surface.attach and/or wl_surface.commit from an API call that is
defined to do so

The above applies also to damage requests and pretty much all (state changing)
requests on protocol objects the application can access (mainly wl_surface).

With all the above restrictions, we are more or less free to define the EGL
operation. In practice this means we have to define exactly which EGL API calls
emit which Wayland requests.


However, the current practice for a long time has been that calling
eglSwapBuffers() calls wl_surface attach, damage and commit. If we change that,
we break existing applications.


If you cannot strictly work with these restrictions then Miguel is on the right
track: add private protocol extension that does what you need, rather than
trying to bend the Wayland core protocol specification. If you need to tell
something to the server-side EGL at client EGLSurface creation time, use a
private extension. If you need to do attach+commit-like operations async or
before eglSwapBuffers, do it in your private extension and use the wl_buffer
only as a marker/reference of when one should really take the newly drawn image
into use (whether or not the image is ready [*]).

[*] Waiting for images to become ready to use must be up to the compositor,
because it needs to sync the window state with it. If you really want to
postpone the wl_surface.commit with the new image in the client, then you also
need to synchronously block the client. Otherwise the window state updates will
be messed up. As for waiting for client rendering completion in the compositor,
I hope we get a nice solution with explicit fences: the compositor can check
the fence to decide when to execute the commit and avoid stalling the whole
compositor by using an older frame until the new one is ready.

The important thing is that the application knows exactly which image is
(going) on-screen, that window state matches the image, and that we do not mess
up the window state set-up with unexpected or missing requests. And of course
the compositor needs to be able to also deliver these promises.

Focusing only on the steady-state frame streaming when no window state is
changed and optimizing that while sacrificing atomicity of state updates is not
ok (even if it is all that games care about). Everything in Wayland revolves
around strictly ordered sequences of requests.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20161116/f52663aa/attachment.html>