[cairo] cairo pattern/glitz patches

Carl Worth cworth at cworth.org
Wed Mar 2 07:13:47 PST 2005


On Sun, 27 Feb 2005 22:51:37 +0100, David Reveman wrote:
>                                                             If no one
> sees any future performance problems with all these mallocs for every
> drawing operation

We never to get to make the code less clean as a way to avoid
performance problems for which we don't yet have any evidence. I can't
imagine a few mallocs getting to be a serious problem, but if they
are, let's witness it before changing the code.

> drawing operation or if someone can come up with a better way to handle
> acceleration hooks I don't mind changing the cairo_pattern_t struct to a
> cairo_surface_t like struct, but otherwise, I think we should stick to a
> union for the pattern.

I definitely prefer using an embedded "base"[*] structure rather than
using the pre-processor hacks. But that's a separate issue from the
question of struct vs. union.

And I don't think we have exclusive options here. If we model
cairo_pattern_t after cairo_surface_t, we can let that structure
appear in the cairo.h typedef. Then, it would still be possible to
build a union out of all the possible pattern types so that you could
do your generic-pattern-on-the-stack thing.

All that would be missing is a name. Maybe cairo_pattern_union_t ?

-Carl

[*] We could name it "super" if people think that's an obviously
better convention. I think one reason I dislike super is that the
super-structure has a subset of the fields of the sub-structure, and
the sub-structure has a superset of the fields of the super-structure.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20050302/87d3d902/attachment.pgp


More information about the cairo mailing list