[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