[cairo] Inefficiency of _cairo_xlib_surface_composite

[Jason Dorje Short]

Bill Spitzak wrote:
> 
> 
> Jason Dorje Short wrote:
> 
>> - If the operation is OVER or SRC and there is a mask, but the mask is
>> only 1-bit (all alpha values either 255 or 0), then XCopyArea can be
>> used with a monochrome bitmap as a mask.
> 
> 
> This is wrong if Cairo assumes images are premultiplied. It would only 
> work if the rgb is 0 where the alpha is 0.

I don't understand this.

> Second, I really doubt real applications are going to use 1-bit alpha 
> enough to make it worth detecting this. I would limit the detection to 
> determining if the alpha is 1 everywhere.

I find that hard to believe.  In my experience, most X applications do 
use 1-bit alpha.  This is because 0-bit alpha is useless, and >1-bit 
alpha is unsupported in traditional xlib.  While XRender does support 
8-bit alpha, without hardware acceleration it is much slower.

As an example changing my X application (which uses a 1-bit mask on 
almost every graphic) to use Cairo makes drawing 6x slower - enough to 
rule out using Cairo, basically.  While it's true that this is really a 
problem in Render not in Cairo, as long as it remains I doubt that Cairo 
will gain acceptance as a replacement for xlib applications.  And while 
I'm all in favor of fixing it in XRender, even if it were fixed there 
would still be problems when running Cairo on older X servers.

If I use xlib directly (or gdk, for that matter) I can write a wrapper 
that uses a 1-bit mask when possible and an 8-bit alpha when needed. 
Since most of my graphics will not have alpha levels, this gives alpha 
support with a very small performance hit (I have tested this with 
gdkpixbuf/gdkpixmap but not with xlib).  However even this isn't 
possible in Cairo because the interface does not support (AFAIK) drawing 
with a mask separate from the src surface.

-jason