<div dir="ltr">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.<div> </div><div>- VirtualPresence.</div></div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Oct 28, 2014 at 12:33 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, 27 Oct 2014 10:15:20 -0700 Virtual Presence <<a href="mailto:virtualpresence.ucla@gmail.com">virtualpresence.ucla@gmail.com</a>> 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 <div class="HOEnZb"><div class="h5"> > On Mon, Oct 27, 2014 at 12:36 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com">ppaalanen@gmail.com</a>> > wrote: > > > On Sat, 25 Oct 2014 17:14:32 -0700 > > Virtual Presence <<a href="mailto:virtualpresence.ucla@gmail.com">virtualpresence.ucla@gmail.com</a>> 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 > > </div></div></blockquote></div> </div>