[cairo] Cairo GLES2.0 backend

Alexandros Frantzis alexandros.frantzis at linaro.org
Wed Nov 17 08:05:25 PST 2010


On Wed, Nov 17, 2010 at 02:22:21AM +0100, Benjamin Otte wrote:
> 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.

The plan is to make a unified backend that can use both GL >= 2.0 and
GLES2.0 by using only the common API present in both GL 2.0 and GLES2.0.
I have tried this approach in the past (in other projects) and it worked
out pretty well.

When there is a very good reason to use API present only in one API, I
would generally prefer to use some kind of wrapper functions/API around
that, so that the high-level code paths don't get disrupted by
#ifdefs. 

Of course, it may be that we can't completely avoid #ifdefs but I want
to make sure that the code doesn't get littered with #ifdef
micro-decisions.

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

The approach I am taking is based on supporting only programmable
pipeline API and shaders, so it is consistent with this goal.

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

Yes, this is interesting and is in tune with the "wrapper functions/API"
approach I wrote about above.

Thanks,
Alexandros


More information about the cairo mailing list