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 <[email protected]> wrote: > On Mon, 27 Oct 2014 10:15:20 -0700 > Virtual Presence <[email protected]> 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 <[email protected]> > > wrote: > > > > > On Sat, 25 Oct 2014 17:14:32 -0700 > > > Virtual Presence <[email protected]> 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 > > > > >
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
