AW: [Cairo] Cairo and 1bpp Bitmaps

Carl Worth cworth at east.isi.edu
Fri Nov 14 07:10:27 PST 2003


On Nov 14, Krieg Andreas wrote:
 > Thanks for the information, I re-arranged the bits and it looks now better,
 > but there are some strange white points and the 'white' middle lines appear
 > not correct.

As Keith mentioned, the A1 surface is intended for holding 1-bit alpha
values, not color. That's probably what's still tripping you up.

 > However, could someone explain to me how the drawing is working in cairo,
 > please (how are the pixels set for a line for example)?

At a particular low level in the current implementation there is a
single image compositing operation that appears in three forms:

composite: 3-operand image compositing: dst <= (src IN mask) OP dst

composite_trapezoids: A special case of composite, where the mask is
defined implicitly by a list of trapezoids.

fill_rectangles: A further special case, where a single pixel-aligned
rectangle is used to define the implicit mask.

Currently, these operations are carried out either by code in libic or
through calls into the Xrender library.

 > Is it possible to create my own surface so that I may use my prefered image
 > formats?

Sure. You would just need to add the appropriate code to libic. And it
may be that libic already supports more formats than are currently
exposed by cairo. One open question is what is the sensible set of
formats that cairo should expose? It seems it would be desirable to
aim for formats that could be supported directly by most backends.
Though with libic in place, I suppose we can always fall back to slow,
software image-based rendering when a requested combination of backend
and format do not get along.

 > Is cairo alywas drawing into a bitmap?

That's pretty much all that is happening today, (though with the
Render extension involved, the "bitmap" is a server object that might
actually be a hardware-composited surface in video memory).

And as we add other backends, this will change considerably.

 > The PostScript surface is just using a image for each page, I think
 > this will be a performance issue when I use big Pages at High
 > Resolutions (the same I think will be a problem with PDF output
 > when we just use a image for each page, think about a large
 > PageSize for example A0 32 * 45 inch with a full color argb32
 > image?).

As discussed recently, the limited imaging model of PostScript
constrains our options here. But with PDF 1.4, the same limitations
aren't there. So, for the PDF backend, I'm very interested in seeing
something other than the simple "image per page" approach. It's just a
simple matter of programming from here I think, (with some likely
reworking of internal cairo interfaces).

 > Some comments would be nice....

I hope that helps.

-Carl




More information about the cairo mailing list