[cairo] Cairo GLES2.0 backend
eric at anholt.net
Tue Nov 16 01:47:45 PST 2010
On Mon, 15 Nov 2010 18:00:11 +0200, Alexandros Frantzis <alexandros.frantzis at linaro.org> wrote:
> Hi all!
> One of the main goals of the Linaro graphics working group (, )
> 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:
> 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?
I'm not really working on it, having too many other things on my plate.
I've mostly used it as a testbed for "is GL fast enough to do 2D
drawing?" The answer so far has been: the GL driver is slower than it
should be, but after much work, it's much better than Xlib.
On my Ironlake graphics, it's failing 72/242 testcases. Many those are
due to an Ironlake GL bug with texture border color, some are due to
radial gradients being flipped vertically (see my recent fix for
linear), and some are due to filtering differences that the testcases is
just too picky about. So, it doesn't look too serious.
> 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)?
I've told many people to just go for it with introducing GLES2.0 compat
in the GL backend. Nobody followed up by actually going for it yet :)
> 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?
No, I don't think so. I wrote it initially while trying to get cairo-gl
up quickly, and it was a mistake to have ever done so. It's a major
impediment to improving cairo-gl. People with fixed-function hardware
will be better served by the image backend regardless, I'm sure.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 197 bytes
Desc: not available
More information about the cairo