On Tue, 29 Apr 2014 16:18:33 -0400 "Jasper St. Pierre" <jstpie...@mecheye.net> wrote:
> Can we at least do this work independently of this patch? I was debugging > EGL stack issues, so I figured I might as well give my envvar hack to debug > SHM issues. Of course, I never intended to block this patch. I just wanted to start a conversation about cairo-egl in toytoolkit in general. > On Tue, Apr 29, 2014 at 4:07 PM, Kristian Høgsberg <k...@bitplanet.net>wrote: > > > On Tue, Apr 29, 2014 at 5:35 AM, Pekka Paalanen <ppaala...@gmail.com> > > wrote: > > > On Mon, 28 Apr 2014 11:19:32 -0400 > > > "Jasper St. Pierre" <jstpie...@mecheye.net> wrote: > > > > > >> --- > > >> clients/window.c | 4 ++-- > > >> 1 file changed, 2 insertions(+), 2 deletions(-) > > >> > > >> diff --git a/clients/window.c b/clients/window.c > > >> index d822af7..3897440 100644 > > >> --- a/clients/window.c > > >> +++ b/clients/window.c > > >> @@ -4338,11 +4338,11 @@ surface_create(struct window *window) > > >> return surface; > > >> } > > >> > > >> -static window_buffer_type > > >> +static enum window_buffer_type > > >> get_preferred_buffer_type(struct display *display) > > >> { > > >> #ifdef HAVE_CAIRO_EGL > > >> - if (display->argb_device) > > >> + if (display->argb_device && !getenv("TOYTOOLKIT_NO_EGL")) > > >> return WINDOW_BUFFER_TYPE_EGL_WINDOW; > > >> #endif > > >> > > > > > > Nice. > > > > > > I wonder, would it be time to finally just drop cairo-egl completely? > > > It does raise the question on what to do with weston-gears and > > > weston-screensaver. ISTR that krh was not fond of using sub-surfaces > > > for them, so... just turn them into simple-egl kind of clients? Did we > > > already have the decorations code easily integrable to non-cairo GL > > > apps, maybe stemming from the wayland-backend work? > > > > I'd like to drop cairo-egl, but not in a way that makes window.c shm > > only. I'd like it to use GL by default and use cairo for rendering > > assets, for example, render the frame in cairo, but use gl to stretch > > and scale it and composite the title on top. Any particular reason why you want to do that? For all toytoolkit apps that do not explicitly need GL, I see using GL as an unneeded overhead. That is especially true for e.g. weston-desktop-shell and the VKB apps which run always. You would still keep the shm-only path as an alternative, right? That would mean no simplification inside toytoolkit as a bonus from getting rid of cairo-egl. If toytookit uses GL or GLESv2, we won't get rid of the incompatibility we have right now, where if you compile with cairo-gles, you simply cannot run weston-gears or weston-screensaver, because those explicitly use desktop GL. If you compile with cairo-gl, you cannot get subsurfaces demo's GLESv2 widget, because again you cannot mix GL and GLESv2 in the same process. We'd have to use something like libepoxy for window.c and write both GL and GLESv2 paths in it, which I think would be going a bit too far for the use cases it is intended for. OTOH, I suppose we could mandate that all toytoolkit apps must be desktop GL apps, iff the app itself wants to use any GL. That would then exclude things like running subsurfaces demo on RPi, which might otherwise be useful for testing. If we went GLESv2 only, we need to throw weston-screensaver out, but that can be replaced if someone wants to, and switch to GLESv2 gears which is probably just a small case of copying some code. Instead what I would propose is, make window.c shm-only, but also add helpers similar to what compositor-wayland.c does to render window.c decorations into a EGLSurface. That way window.c would not restrict what GL an app can use, but would still support apps using any flavour of GL. Or would you rather have window.c support everything? As part of window.c init, app tells it which GL flavour has been linked in if any, and then it adapts at runtime? I think I'd rather see window.c going in the simpler direction when possible, after all it is not supposed to be a real versatile toolkit. Is it? Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel