[PATCH 6/6] window: Add a simple getenv to force SHM rendering

[Pekka Paalanen]

On Tue, 29 Apr 2014 16:18:33 -0400
"Jasper St. Pierre" <jstpierre at 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 <krh at bitplanet.net>wrote:
> 
> > On Tue, Apr 29, 2014 at 5:35 AM, Pekka Paalanen <ppaalanen at gmail.com>
> > wrote:
> > > On Mon, 28 Apr 2014 11:19:32 -0400
> > > "Jasper St. Pierre" <jstpierre at 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