[cairo] cairo pattern/glitz patches

[Kristian Høgsberg]

Carl Worth wrote:
> 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.

In this case it's also an extra error path that we need to handle. 
Currently, _cairo_pattern_init_copy() never fails, which is quite easy 
to work with.

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

I like this idea, we may have to add .u or .base here and there, but I 
don't think it will be much more compared to Davids patch.  And it has 
the nice property from Davids patch, that we can pass a, 
cairo_radial_pattern_t around when we know that's what we're dealing 
with, using the same technique as for cairo_surface_t and avoiding the 
preprocessor hacks.

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

( If you think of types as equivalent with the set of all values of the 
type, it probably makes more sense.  The set of values for the super 
type is a super set of the set of values for any of its subtypes.  The 
set of values for a subtype is always a subset of the values for its 
supertype.  Anyway, I see no reason to change base to super, base makes 
good sense to me. )

Kristian