[cairo] GL backend work

[Zach Laine]

On Sat, Jan 9, 2010 at 10:03 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> On Sat, 9 Jan 2010 13:40:43 +1800, Zach Laine <whatwasthataddress at gmail.com> wrote:
>> On Sat, Jan 9, 2010 at 7:17 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
>> No problem.  I'll start this soon.  First, I want to make sure we're
>> not working at cross-purposes.  What does the regression summary
>> report for you from a fresh checkout of master?  Are you even working
>> in master?  Your comment below about wip/compositor suggests you're
>> not.
>
> I haven't done serious work on master for months. :( My little side branch
> gradually became a combination of sweeping architectural changes, new
> features and bug fixes. :((

Ok, then I'm confused.  Do you still want me to submit patches against
master, or against wip/compositor?  Some of my patches apply to both
branches, but many do not.

> http://cgit.freedesktop.org/~ickle/cairo/log?h=wip/compositor is the
> current state of broken affairs. I'm in the middle of fixing up the last
> of the broken backends (which include cairo-gl at this point, the spans
> interface should be 'complete' but the composite-fallbacks need work to
> accommodate the lack of shaders).

I'm not sure what you mean by, "to accommodate the lack of shaders"
here.  Was there ever an implementation that did use shaders, or are
you referring to something else?

>> Of course.  However, since there are two backend functions paint() and
>> fill(), there are two code paths.  There is no way I know of to
>> enforce that fill() is implemented in terms of paint(), except by
>> testing that both paths do the right thing.  This applies in lots of
>> other places.
>
> True, and I fully acknowledge that our test suite can always be improved.
> However, the point I'm trying to make is that there is little difference
> between paint and fill et al.

All the more reason to provides tests to ensure that uniformity exists
in the behavior and not just the interface, no?

> Instead of shaders for the 5 high level
> entry points,

Did you think I was suggesting this?   I'm unclear why you've written this.

> what I've found works well so far is to classify the
> operation in terms of different fundamentals: e.g. pixel-aligned composite,
> spans [non-pixel-aligned composite], and glyphs. And then use JIT shader
> generation.

I agree with this in principle, except that I don't know exactly what
JIT generation you have in mind.

> What I have in mind is something like:
> http://cgit.freedesktop.org/~ickle/cairo/tree/src/drm/cairo-drm-i965-surface.c?h=wip/compositor#n1118
>
> Different algorithms may require different classifications, but having
> made the switch to only use the high level path interfaces, we can
> decompose the task however we need to.

Ok.

> Hope this helps, once I've got cairo back on the road to 1.10, we should
> be in a stronger position to do interesting things with cairo-gl.

Again, this leaves me a little unclear as to how best to proceed.

Zach