Drawing CSD on EGL apps

[Samuel Rødal]

On Mon, Nov 5, 2012 at 9:31 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I replied privately to this but here is a more concise reply.
>
> Samuel Rødal wrote:
>
>> In OpenGL ES 2.0 and modern desktop OpenGL there is no concept of a
>> projection matrix state...
>
>
> I am aware of this. But most applications provide utility functions that
> maintain state (such as the location of the viewing camera) and expect their
> drawing routines to call these. So such restrictions on what OpenGL code can
> be used already exist and programmers are used to them.

Sure, applications can be rewritten to render to a sub-rectangle of
the framebuffer, but it's not very nice to require them to do so if
there are other solutions. The ideal from Qt's point of view would be
that existing applications would be able to run as Wayland clients
without any modifications to their source code, just as they're
currently able to run on Windows, Mac, and X11.

>> applications like Blender draw their own UI components.
>
> This is true of a suprising number of pieces of commercial software used in
> cgi. They are all drawing OpenGL into subrectangles, so this is proof that
> it is not impossible with current OpenGL.
>
> The reason X and Windows programs use subwindows is that it is impossible to
> use other drawing libraries in the same window as the OpenGL. Blender and
> all this other software solves this by drawing all their widgets in OpenGL.
> But if you use Qt or any other toolkit that does not use OpenGL to draw the
> widgets, you are forced to use the subwindows.

Qt has already been moving toward OpenGL as the rendering API, even
going as far as making it a requirement for running QML 2 applications
in Qt 5. Qt can adapt to draw scrollbars or other UI components using
OpenGL (as textures if need be). We would however like to be able to
keep giving the application programmer a dedicated (or seemingly
dedicated, from the OpenGL API point of view) surface to render into.

>> 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.
>
>
> I agree this would be useful, but it is not the *requirement*.
>
> The requirement is that it be possible for non-OpenGL libraries to draw into
> the same buffer the OpenGL. To me this implies that wayland buffers must be
> memory mapped as writable buffers in client memory space.

That seems like the wrong approach, as mapping GPU buffers in client
memory space can be very expensive, and you end up paying heavy
synchronization costs by preventing the GPU from rendering into the
buffer at the same time (GPUs like pipelining and asynchronous
rendering). Toolkits should instead adapt by rendering things like
window decorations by blitting textures (which can still be generated
CPU side and cached in GPU memory).

> It is tempting to say that a Cairo or Pixman-style OpenGL backend will solve
> this but I have my doubts, especially if non-OpenGL programs are not using
> it. And there is just a ton of stuff that wants to fiddle with pixels
> directly.

Cairo and Qt just need efficient ways of getting client memory buffers
into GPU textures.

--
Samuel