Drawing CSD on EGL apps

[Bill Spitzak]

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.

 > 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.

> 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.

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.