Drawing CSD on EGL apps

[Samuel Rødal]

On Sun, Nov 4, 2012 at 10:24 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I think this problem needs to be solved for putting scrollbars and docked
> panels and all kinds of other graphics around the OpenGL viewport.
> Special-casing window borders is not the solution.
>
> It is true that the solution I have seen on both X and Windows is to make a
> child window and draw the OpenGL into that. This produces all kinds of nasty
> graphics artifacts when windows are resized or internal layout changes. I
> think there will be a need for "subwindows" in Wayland (though they are not
> inside, just stacked, with the shell keeping them together). These are going
> to be needed so the subwindow can have a different color space or transform,
> but it seems wasteful to use this for restricting OpenGL.

Yep, that's the solution Qt has used too, a QGLWidget always being a
native child window/surface. I agree that it's not ideal.

> The other solution that is closer to what I recommend is to use scissor and
> the projection matrix to restrict drawing to a given subrectangle, and the
> client code is just not supposed to do OpenGL calls that will break that. On
> X (and I think on Windows) this has the unfortunate side-effect that you
> have to use OpenGL for *all* drawing in the window. It would be nice if
> wayland (or egl?) fixed this. Another way is to use an OpenGL backend for
> Cairo to draw these parts.

In OpenGL ES 2.0 and modern desktop OpenGL there is no concept of a
projection matrix state, it's all uniforms set on the currently active
shader program, and those are set by the application code. Well, even
in fixed function OpenGL the application would typically do
glMatrixMode(GL_PROJECTION); glLoadIdentity(); etc. I don't think it's
trivial to port any OpenGL application that expects to render to the
full viewport to one that respects a given scissor rect, as they
probably often contain a lot of hard-coded logic.

> As far as I can tell all large 3D applications (like Maya) either go the
> all-OpenGL route, or they use Qt and subwindows.
>
> In any case I am very wary of any solution that treats the window borders as
> special. The solution must also solve putting scrollbars around the openGL
> or it is not a correct solution. It would be really nice if the solution did
> not require creating otherwise useless extra surfaces.

Most games don't really have scrollbars, and applications like Blender
draw their own UI components. I agree that it would be nice to not
create extra surfaces, but I think the cleanest way to do that would
be an EGL extension, otherwise pretty much all existing OpenGL code
will have to be modified in various ways in order to be ported.

The EGL extension would be some way of defining an EGLSurface to be
part of a larger  EGLSurface and being able to make that sub-surface
current, and to swap the sub-surface. The swap would probably be a
no-op or set a flag, so actual swapping would be done on the larger
surface.

Until there is such an extension Qt will probably have to use FBOs or
multiple wl_surfaces to implement client side window decorations for
existing Qt based OpenGL applications.

--
Samuel