Reusing wl_egl_window for multiple EGL surfaces

[Pekka Paalanen]

On Mon, 27 Oct 2014 10:15:20 -0700
Virtual Presence <virtualpresence.ucla at gmail.com> wrote:

> I see. Thank you for the info. What i am trying to do is have multiple
> contexts with its own EGLSurface but sharing the same "window" or
> wl_surface on wayland, where one thread renders a gl_triangle and the other
> rendering gears. This was a simple client to teach myself queues and IPC of
> wayland, ofcourse it doesnt reflect "real world" clients. So with this
> setup i was wondering if a resize on the wl_egl_window will seamlessly take
> effect on both EGLSurfaces. Since there is no spec could it be possible
> that different wayland EGL implementations will have different
> interpretations on if/how to reuse the wl_egl_window OR are implementations
> explicitly discouraged, may be to prevent themselves from blowing up in
> weird ways, from reusing the same wl_egl_window concurrently? Also i am
> assuming reuse of the wl_egl_window non-concurrently is permitted and wont
> have issues?

I think that is all unknown territory. I'm not sure anyone has ever
even considered that one might actually intentionally use the same
wl_egl_window to create several EGLSurfaces. The output to screen is
not sensible, because even if the implementation copes with multiple
EGLSurfaces, the EGLSurfaces would still be fighting over whose buffer
is actually shown on screen.

Resize is not really an issue on its own, but just a part of the whole
problem, whether an EGL implementation actually supports having
multiple EGLSurfaces for a single wl_egl_window.

In my opinion, it is reasonable to assume, that implementations do not
support one wl_egl_window to multiple EGLSurface associations. But,
wl_egl_window is a cheap wrapper anyway, so I would recommend thinking
it as an extension of the EGLSurface object, offering an API for
resizing, because the EGL implementation cannot get resizing
notifications from anywhere else. So you should be able to create
multiple wl_egl_windows from the same wl_surface. I cannot think of any
obvious problems that would raise, and you can have your content
fighting as you wish. Just keep the wl_egl_window together with the
EGLSurface in terms of thread context etc.

Re-using a wl_egl_window by first destroying the EGLSurface and then
creating another EGLSurface should probably work, I think, though
that's again something I doubt anyone has ever tried before.

AFAIK, we are very much missing a specification defining all these
details, and there are no EGL implementation conformance test suites to
validate any implementation on the Wayland platform. Fixing this would
be seriously beneficial, but we're not there yet.

So, are you trying to show the triangle and gears randomly alternating,
or what do you actually expect to see on the screen?

If you want the triangle in one part of the window, and the gears on
another part, you could do that with sub-surfaces. One possible surface
hierarchy is that you have the window, and then you create a new
wl_surface for triangle and gears each, and tie these wl_surfaces to
the window's wl_surface by using wl_subcompositor interface.


Thanks,
pq

> On Mon, Oct 27, 2014 at 12:36 AM, Pekka Paalanen <ppaalanen at gmail.com>
> wrote:
> 
> > On Sat, 25 Oct 2014 17:14:32 -0700
> > Virtual Presence <virtualpresence.ucla at gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I am writing a simple multi-threaded multi-context GLES2 Wayland client.
> > As
> > > required by Wayland and MESA EGL bindings i do create a wl_egl_window to
> > > pass on to EGL window surface creation. I was wondering if there is any
> > > spec or rule that disallows reuse of the same wl_egl_window for multiple
> > > EGLWindowSurface. I was wondering if i could use the same underlying
> > > wl_egl_window resize bindings to cause multiple resizes. If i cannot do
> > the
> > > same i would like to know of a spec/rule/guide (say like an EGL spec)
> > that
> > > lists all the creation, management, deletion and usage of this object.
> >
> > Hi,
> >
> > I cannot understand what you could possibly achieve by creating several
> > EGLSurfaces for the same window. What do you want to do?
> >
> > Are you perhaps attempting to render different parts of a single window
> > in different GL contexts and so using different EGLSurfaces with some
> > clipping magic? Maybe relying that GLX (not EGL IIRC!) required the
> > color buffers to be shared between clients/contexts?
> >
> > Or do you simply want a dummy EGLSurface for each context, and then use
> > FBOs to do the work, without ever calling eglSwapBuffers except for the
> > one context that actually draws in the window? Because there are no
> > Pixmaps in EGL Wayland?
> >
> > I can't quote a spec off-hand, but I know the EGL Wayland platform does
> > not support "partial" rendering. Every time you call eglSwapBuffers,
> > the whole buffer content must be valid, as the display server is free
> > to take the whole buffer as the new window contents. That's actually a
> > Wayland specification: every buffer must be completely drawn, as the
> > display server is allowed to use all of it, even if the associated
> > damage is only a part of it.
> >
> > So, I don't think it is explicitly forbidden anywhere to create several
> > EGLSurfaces for the same wl_egl_window, but it just doesn't make sense.
> > The different (E)GL contexts using the different EGLSurfaces would be
> > fighting over whose buffer ends up on screen. As such, I expect that
> > case to be untested, and so likely hit bugs.
> >
> > FWIW, you'd be looking for an EGL Wayland platform specification, and
> > one has not been written AFAIK, as has not been written for many of the
> > other platforms either.
> >
> >
> > Thanks,
> > pq
> >