Reusing wl_egl_window for multiple EGL surfaces
Pekka Paalanen
ppaalanen at gmail.com
Mon Oct 27 00:36:49 PDT 2014
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
More information about the wayland-devel
mailing list