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

[Owen Taylor]

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?

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

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

(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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050128/d20aacc1/attachment.pgp