[cairo] GL backend work
whatwasthataddress at gmail.com
Fri Jan 8 11:40:43 PST 2010
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!
> 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
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
> 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.
> 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
> 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
>> 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?
More information about the cairo