[cairo] Cairo GLES2.0 backend

Benjamin Otte otte at redhat.com
Tue Nov 16 17:22:21 PST 2010


Thought I'd list my ideas, as Eric and me have been the last people to
touch most of the code.

First of all, it looks like a bad idea to be targetting multiple GL
implementations in the code's current state. So I'd favor if we didn't
have lots of ifdefs that we all need to test whenever we refactor stuff.
(We can keep the ifdefs for all I care, I just don't want to test more
than one configuration.)
We should try to make it easy to add support for new GL versions, so we
shouldn't remove that possibility with refactorings.

That said, woever does something serious with the code gets to decide
what implementation we are using. I don't care if that is going to be
GLES or GL. So if you are going to write the code and want to focus on
GLES, we take that as the supported configuration. Fine with me.


Also, you might be interested in my current refactoring goals (that I
probably won't get to in the near future):

1) Rip out the fixed function code
By now Mesa is good enough to handle the shaders we throw at it and the
hardware certainly hasn't gotten worse. That should clean up a lot of
messes that we currently have.

2) Split out the vertex array handling
That way, we can introduce a nice API that we can later abstract to
something portable. Probably similar to CoglVertexBuffer. That should
simplify GL vs GLES, too.


Looking forward to patches,

Benjamin


On Mon, 2010-11-15 at 18:00 +0200, Alexandros Frantzis wrote:
> Hi all!
> 
> One of the main goals of the Linaro graphics working group ([1], [2])
> for this cycle is the implementation of a GLES2.0 backend for cairo. The
> main plan is to use the existing GL backend and modify/extend that
> instead of starting yet another backend.
> 
> The current work plan can be found at:
> 
> https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Specs/1105/CairoGLES2Backend
> 
> This is still tentative and will be greatly influenced by the feedback
> received from the list. The goal is to work closely with upstream and
> any other groups that are working on this, so that we can together
> achieve the best possible results.
> 
> Some information that would be great to know before reviewing the plan:
> 
> 1. Is someone currently actively working on the GL backend that is in
>    master? What is the state of the backend?
> 
> 2. Is there upstream interest for a GLES2.0 backend? Is anyone aware of
>    an effort to introduce GLES2.0 compatibility to the GL backend (or a
>    completely new backend)?
> 
> 3. In order to reduce code complexity and maintenance issues I was
>    thinking it would be better to provide a single backend for GL >= 2.0
>    and GLES2.0, either by using only GL2.0/GLES2.0 compatible
>    functionality or at least by maximizing code sharing and minimizing
>    special cases.
> 
>    However, at this point there is a lot of fixed-function code in the
>    GL backend. Do you think it is necessary to maintain the current GL
>    1.x compatibility?
> 
>    If 1.x compatibility is deemed necessary then I believe the best way
>    forward is to extend the current runtime selections (eg like ARB vs
>    core 2.0 in cairo-gl-shaders) or have compile-time selections where
>    necessary.
> 
> 4. Any other thoughts on requirements for upstream inclusion of a
>    GLES2.0 compatible backend?
> 
> Any comments and feedback are highly appreciated!
> 
> Thanks,
> Alexandros
> (alf on IRC)
> 
> [1] http://www.linaro.org
> [2] https://wiki.linaro.org/WorkingGroups/Middleware/Graphics
> --
> cairo mailing list
> cairo at cairographics.org
> http://lists.cairographics.org/mailman/listinfo/cairo




More information about the cairo mailing list