[Mesa-dev] [PATCH] wayland/egl: initialize window surface size to window size

[Pekka Paalanen]

On Tue, 05 Jun 2018 19:22:47 +0200
"Juan A. Suarez Romero" <jasuarez at igalia.com> wrote:

> On Tue, 2018-06-05 at 12:41 +0100, Daniel Stone wrote:
> > Hi Juan,
> > 
> > On 5 June 2018 at 09:51, Juan A. Suarez Romero <jasuarez at igalia.com> wrote:  
> > > On Mon, 2018-06-04 at 13:22 +0100, Daniel Stone wrote:  

> > > > Yes, that's correct, and I believe eglMakeCurrent() does perform that
> > > > attachment. The NVIDIA/EGLStreams implementation is extremely broken
> > > > in that regard, in a way which does break genuine real-world
> > > > applications. We had a long discussion on wayland-devel@ when the
> > > > EGLStreams implementation was first posted, detailing the ways in
> > > > which their implementation causes genuine problems for real-world
> > > > users, and can provoke client deadlocks. I am very opposed to
> > > > supporting or codifying that behaviour.  
> > > 
> > > So I understand eglSwapBuffers() is required to do the attachment.  
> > 
> > It is required to do an attachment, yeah.
> >   
> 
> Nice. The other failing test in CTS is not calling eglSwapBuffers()
> before doing the first wl_gl_window_get_attached_size(), and hence
> when we call it we get null values.
> 
> So it seems the fix must be done in CTS, bycalling eglSwapBuffers()
> to ensure the window has an attached buffer, before getting the size.

Hi,

I would like to try to clarify the mental model here. The term
"attached" is somewhat of a misnomer. But this may also be confusing,
because I am bringing in underlying details of Wayland which no other
window system has AFAIK.

It is true the Wayland request is called wl_surface_attach(wl_buffer).
Alone it does essentially nothing, it requires a wl_surface_commit() to
become effective. eglSwapBuffers() always does both before returning,
so that is fine.

Intuitively "attach" implies that one creates an association between
two objects and then one can continue working on the attached object
(buffer). This is where the misnomer becomes apparent: it would be
better to talk about submitting, not attaching. eglSwapBuffers is
submitting the current WIP buffer to the compositor to replace the
contents of the Wayland wl_surface (window). One cannot resize or draw
into the submitted buffer as long as it is held reserved by the Wayland
compositor, to be released with wl_buffer.release event.

A Wayland window (wl_surface) has no initial size. Only submitting
(attach+commit) a wl_buffer will give the wl_surface a size, that is,
calling eglSwapBuffers resizes the window.

Only the client itself can resize the window e.g. by calling
eglSwapBuffers, the compositor or any third party cannot resize the
window, so there is no way to query the window size via Wayland.

From an EGL application point of view, a window has two different
concepts of size: the size that is currently being used (with e.g.
input events) which is the size of the wl_surface and returned by
wl_egl_window_get_attached_size(); and the size of your current
unfinished drawing which will become the wl_surface size on the next
call to eglSwapBuffers.

wl_egl_window_get_attached_size() would more appropriately be described
as returning the size of the last submitted buffer.

When I talked about wl_surface size in the above, I was actually using
a generally incorrect simplification. The wl_buffer size determines the
wl_surface size (now I am using the specific Wayland terms here), but
they may not be equal. Buffer scale and transform and wl_viewport are
Wayland protocol features that change how the wl_surface size is
computed from the wl_buffer size. However, all these are outside of EGL,
in the EGL user instead, and EGL itself will be unaware of these.
Therefore EGL Wayland can only concern itself with buffer dimensions,
the actual wl_surface size will remain unknown to it.

Therefore, when interpreting the EGL specifications, when it talks about
"window size", on Wayland you can really only think about the WIP or
submitted buffer size.

I would say that for EGL purposes, the current native window size is
the last submitted buffer size and it is zero initially.

For the CTS, one may want to test wl_egl_window_get_attached_size and
the WIDTH/HEIGHT queries separately to ensure both are as expected (I
agree to Daniel's interpretation here).


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20180611/1a907dcc/attachment.sig>