Reusing wl_egl_window for multiple EGL surfaces

[Virtual Presence]

Thank you for the detailed gyaan. I will look into the "sub-surface"
protocol as an alternative. What I do as of now is have the 2 threads on a
3 second timer where threadA renders triangle for 3 seconds then signals a
mutex condition and wakes up threadB which renders gears for 3 seconds and
so on and so on. I will also look into the option of reusing the wl_surface
for multiple wl_egl_window. This seems closest to what i had in mind. I
would also like to attach 3 second timer signal to the display FD and the
custom queue i have setup for the 2 threads so that instead of having a
dedicated timer logic I can blend the event handling into the Wayland
model. I haven't been successful in doing this though. As an alternative I
am looking into the option of writing a wl_timer protocol to provide the
functionality. Any suggestions on how i can tie in the timer logic or any
comments on having a dedicated wl_timer protocol? Thank you for all the
help.

- VirtualPresence.

On Tue, Oct 28, 2014 at 12:33 AM, Pekka Paalanen <ppaalanen at gmail.com>
wrote:

> 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
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20141029/6e6293f5/attachment-0001.html>