[cairo] GL backend work

[Zach Laine]

On Sat, Jan 9, 2010 at 7:17 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Hi Zach,
>
> On Fri, 8 Jan 2010 20:48:30 +1800, Zach Laine <whatwasthataddress at gmail.com> wrote:
>> I've recently been working on the OpenGL backend on a repo hosted on GitHub:
>
> Thanks for looking at and working to improve cairo-gl!

My pleasure!

> Seems like you found
> cairo-gl in a state of disrepair, which puzzled me since it had very few
> failures last time I checked with Intel (gm45) and Nvidia
> (nv48/185.xx.xx).

Well in turn that puzzles me.  A fresh checkout of master shows a
regression summary of 255/219/10/0 for NVidia 190.x, and 250/222/12/0
for Mesa 7.4.

> Looking through your git tree, you've made a number of
> controversial changes which probably deserve some explanation.

I make no claims that I've got the right solutions, just that the
solutions I've implemented fix the regression tests.  I'm certainly
open to other alternatives.

> If you use
> IRC, then we all hang out on irc.freenode.net #cairo which is the best
> place if you need some explanation on why the code is sometimes a bit
> peculiar or if you want some quick review on a change.

I generally don't, but I'll try to stop by for quick answers.

> I'd like to see of those patches submitted to this list for review. At
> the moment your branch is a bit of a mess with experiments (something I'm
> equally guilty of), so if you can clean up one or two patches and submit
> those to get the process started. (The eventual goal is for you to earn
> commit access, and the confidence to make minor changes directly. :-)

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.

> The first step is to create a proper git commit log entry. The first line
> of the entry is a single line (max ~70 characters) saying what changed.
> For cairo, we use "subsystem: Use foo with bar". Then there is a blank
> line, followed by one or more paragraphs explaining why the change is
> required, including references to email conservations and bug reports.
> Carl likes to aim for around 80 lines of explanation for every single
> one-line change he makes. (For he tends to fix extremely subtle bugs ;-)
>
> And remember each patch should just do one thing.

Sure.

> Also I'm hesitant to workaround driver bugs. We've made that mistake in
> the past with xlib and consequently the drivers were never fixed. (This is
> a major reason why I dislike working on closed stacks.)

I'm not really sure what you're referring to here, but if what you're
saying is that platform/driver-specific hacks are to be avoided, I
agree completely.

> Ah, hopefully you've realised that all cairo operations are the same with
> different forms of implicit masks... [Paint is just a single special case
> where the mask is completely opaque.]

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.

>> Futute Work:
>> ============
>
> Note, everything is completely different in wip/compositor which I'm
> working on merging for the basis of 1.10. Our next goal for cairo-gl is
> indeed to perform all operations as basically spans/glyphs+shader,
> as demonstrated by cairo-drm.

Err, ok.  Where do I find such a thing?

Zach