[cairo] GL backend work

[Chris Wilson]

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
(nv48/185.xx.xx). Looking through your git tree, you've made a number of
controversial changes which probably deserve some explanation. 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'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. :-)

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.)

[snip]

> New Work:
> =========
> 
> In addition to fixing regressions, I added some new functionality.  I
> implemented several more cases in _cairo_gl_surface_paint().  It only
> implemented CAIRO_OPERATOR_CLEAR before.  For all supported
> CAIRO_OPERATOR_*'s, it now paints: constant color patterns, surface patterns,
> and gradient patterns (though these are nonfunctional due to the shader
> texturing issue).  These code paths are far shorter than the fallback of using
> the much more general _cairo_gl_surface_composite().  They do things in a much
> smaller number of GL calls, and use shaders where appropriate, such as the
> gradients.

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.]

> Notes and Concers:
> ==================
> 
> In several places in cairo-gl-surface.c, I've included C++-style "// ..."
> comments.  I used this form only so that they would stand out from the C-style
> "/* ... */" comments.  I consider these temporary, thus the break with the
> coding conventions, Some of these are notes for myself, but the majority are
> potential problems I've spotted in the code.  Please have a look and we can
> discuss these concerns on-list.  Many of them are more requests for
> clarification of what's happening at that point in the code -- they're not
> necessarily claims of having found a bug.

For these, you [and we would] get quicker feedback using IRC. However, if
email is preferable, raise the points in question on the list.

> 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.
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre