[cairo] Notes on implementing Cairo with GDI

[Owen Taylor]

When our target is a DIB (or a raw image without a DIB wrapper), most
rendering is best done with libpixman rather than with the GDI. If the
target is a Window or DDB, then we don't have direct access to the
bits, so we have two options. Either we can get the bits from the
target, draw, then put back. Or we can use GDI primitives to do the
drawing directly.

A few operations can be done directly with the GDI ... we can
implement fill_rectangles() with alpha=1.0, op=SRC/OVER. We can
implement composite_trapezoids() with a solid colored source,
op=SRC/OVER if the trapezoids are all pixel aligned. We may be able to
implement composite_glyphs() with a solid colored source,
op=SRC/OVER. We can implement composite() with a ARGB source, op=OVER.

There are some tricks that allow us to expand the range of operations
that can be efficiently implemented.

One trick is solid color tracking. If when creating a Win32 surface,
we are hinted that the surface is a solid color, or we detect the
surface being cleared to a solid color later, then we can track what
portions remain solid-colored and optimize out the "get" out of "get,
draw, then put back".

Another trick is to reduce a more complicated operation to compositing
ARGB with op=OVER. For example, compositing a solid color though a A8
mask isn't possible with the GDI, but if we expand the A8 mask to a
ARGB32 image, we can then composite the result using AlphaBlend(),
taking advantage of hardware acceleration on some drivers.

Now, drawing to a window directly is fundamentally uninteresting ...
drawing is double-buffered in virtually all modern applications.  We
can always create the double-buffer as a DIB and do all software
rendering. The question is whether by using the above tricks we can
make drawing to a DDB *faster* then drawing to a DIB. If we can get
there, then using a DDB for the double buffer is a win.

It's going to depend quite a bit on the mix of operations; a typical
app is largely drawing solid fills and text. These are things we do
with GDI very quickly. But an application that is doing large numbers
of of non-OVER operations is going to be slow to a DIB.

It's also possible to have schemes where we shadow a DDB with a
peristantly with a DIB, or cache retrieved bits as a DIB across
multiple operations. It's not clear that the complexity involved in
doing that is a win.

-------------- 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/20050121/3c9ddbe7/attachment.pgp