[cairo] GL backend work

[Chris Wilson]

On Tue, 12 Jan 2010 11:56:28 -0600, Zach Laine <whatwasthataddress at gmail.com> wrote:
> On Tue, Jan 12, 2010 at 6:09 PM, Eric Anholt <eric at anholt.net> wrote:
> > commit dbda90996852e67e4b766d46cc08b58cb96aee55
> > Author: T. Zachary Laine <whatwasthataddress at gmail.com>
> > Date:   Fri Dec 25 01:01:27 2009 -0600
> >
> >    A major step in the right direction for the span renderer.  It seems that the
> >    span renderer was only setting the alpha channel in the color values in its
> >    VBOs.  It now passes through the span renderer's fixed color, for constant
> >    color rendering, or rgba(1.0, 1.0, 1.0, prev_alpha) if the source is a
> >    texture.  The ft-text-vertical-layout-type3 test still fails.  This was the
> >    test I was attempting to fix with these changes.  At least the colors are a
> >    lot closer now.  I still have to figure out why the alpha values are
> >    off.
> >
> > Not sure what's going on with this one.  The span renderer is setting up
> > the source operand like normal using shared code -- GL_TEXTURE0 unit
> > produces the constant color or the texture color or whatever for the
> > source.  The color provided by the spans is used in GL_TEXTURE1 blending
> > to multiply the mask alpha by GL_TEXTURE0.  So the color of that should
> > be entirely ignored.  It looks like you ended up multiplying by source
> > alpha twice in the case of a constant source.
> 
> Yeah, this is the change I'm least happy with.  It still doesn't do
> the right thing, in that the final color values still aren't quite
> right, but the code before my changes was rendering all constant-color
> spans in black, so it seemed at least to be an improvement.  AFAICT,
> my current output for constant color spans is very similar to the
> wip/compositor output (they're both failing, but look visually very
> close to the ref image).

As I've just started to perform bug fixing on cairo-gl in wip/compositor, I
can tell you what the bug was here...  (Sometimes I despair for myself.)

@@ -557,7 +540,7 @@ _cairo_gl_clip_and_composite_spans (cairo_gl_surface_t              *dst,
        goto CLEANUP;
 
     _cairo_gl_set_destination (dst);
-    _cairo_gl_set_operator (dst, CAIRO_OPERATOR_SOURCE);
+    _cairo_gl_set_operator (dst, op);
   

Now I've just lots of silliness to do with the intel driver retaining bo
beyond finalizing bufmgr, us holding onto references in the glyph cache
and handling fallbacks. And probably many more silly bugs like the above.

Not to mention that the whole thing fails spectacularly on pthread-similar
and pthread-same-source. MESA_multi_thread_context, anyone? ;-)
-ickle

-- 
Chris Wilson, Intel Open Source Technology Centre