[cairo] some fixes and improvements to current cvs version of cairo

[David Reveman]

I've fixed the issues and attached an updated patch.

It includes a fix for the _cairo_gstate_init bug. This fix adds a
default_pattern to the cairo_gstate struct and cairo_set_rgb_color can
use this without allocating and destroying patterns all the time, and
cairo_gstate_init can no longer fail. What do you think?

On Fri, 2005-01-28 at 15:01 -0500, Owen Taylor wrote:
> On Fri, 2005-01-28 at 20:34 +0100, David Reveman wrote:
> 
> > ok, that should all go away then. But we'll have to do something to the
> > xlib/xcb/image backends, as _cairo_pattern_get_surface will otherwise do
> > overall-alpha with an intermediate surface.
> 
> Make _cairo_pattern_get_surface() take a boolean "need_alpha" or
> something like that and add a separate _cairo_pattern_get_mask?

I've added some code to the xlib, xcb and image backend that handles
this pretty well.

> 
> > > (Seems you could use overall alpha for GL as well in a few cases
> > > 4-channel-texture * alpha over dest is possible with GL_MODULATE,
> > > right?)
> > 
> > Yes, repeating 1x1 surface in glitz are internally handled as solid
> > colors. So, when a repeating 1x1 surface is passed as mask to the
> > composite function, glitz will do GL_MODULATE with the source surface.
> 
> One of the ideas of the pattern rewrite was not to force other backends
> to understand the RENDER idiom of 1x1 repeating surfaces for solid
> colors; I don't know if that's useful for glitz, since it's trying
> to be compatible with RENDER...

yes, for glitz, 1x1 repeating surfaces for solid colors is good, for the
cairo surface backend it's bad.

> 
> > > It would be
> > > considerably more efficient to trap errors and just try it ... one 
> > > roundtrip instead of two. Or just assume that the server is going
> > > to be OK at optimizing this case. Or, since we are already have most
> > > of this information when creating the surface save that and use it.
> > > 
> > > But I don't think the above change is better than just commenting
> > > out the fast path.
> > 
> > I didn't really want to get this ugly thing into cairo, I just got tired
> > of this fast path constantly crashing some of my cairo applications
> > after each time I did a cvs update.
> 
> Are you using a 16pp display? Thinking about this some more, the depth
> check isn't sufficient to know that CopyArea is OK. CopyArea is OK only
> if:
> 
>  - The two drawables have the same visual and colormap
>  - The drawables are pixmaps without visual/colormap and have the
>    same cairo_format_t.

correct, but at least it wouldn't give me an XError. ;-)
> 
> (Mismatched root windows is sort of nice to handle. But the app would
> have to be trying to cause such an error.)
> 
> >  I think this ugly code is a good
> > example to why we don't want this kind of checking for fast paths in the
> > xlib and xcb backends, a solution that trapped errors wouldn't be very
> > pretty either. If someone could come up with a nice way to do this, that
> > would be great, but for now, I believe that just commenting out this
> > fast path, is definitely the best solution.
> 
> If we want to have decent non-RENDER support, we need to have these
> sorts of fast-paths eventually. But I'd agree that fast-pathing around
> RENDER doesn't usually make sense.
> 
> Regards,
> 						Owen

-David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cairo-fixes-2.diff
Type: text/x-patch
Size: 28198 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050128/59a93783/cairo-fixes-2.bin