[cairo] cairo pattern/glitz patches

[David Reveman]

On Wed, 2005-03-02 at 10:13 -0500, 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, we discussed changing the code from the known fast method
to using a few mallocs And we wouldn't really make the code any cleaner
either, so changing to using malloc for temporary patterns seems like a
bad idea.

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

We get a lot of pattern->base.xxx in the code but that's OK. Especially
as the already got this in the backends with cairo_surface_t.

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

OK, that would work.

Something like this?

struct _cairo_pattern_t {
	cairo_pattern_type_t	type;
	cairo_matrix_t		matrix;
	cairo_filter_t		filter;
	cairo_extend_t		extend;
	double			alpha;
};

typedef struct {
	cairo_pattern_t	base;

	double red, green, blue;
} cairo_solid_pattern_t;

typedef struct {
	cairo_pattern_t base;

	cairo_surface_t *surface;
} cairo_surface_pattern_t;

If we need this gradient sub-type could be discussed, I think it's nice.

typedef struct {
	cairo_pattern_t	base;

	cairo_color_stop_t	*stops;
	int			n_stops;
} cairo_gradient_pattern_t;

typedef struct {
	cairo_gradient_pattern_t base;

	cairo_point_double_t p0;
	cairo_point_double_t p1;
} cairo_linear_gradient_pattern_t;

typedef struct {
	cairo_gradient_pattern_t base;

	cairo_point_double_t	center0;
	cairo_point_double_t 	center1;
	double 			radius0;
	double			radius1;
} cairo_radial_gradient_pattern_t;

typedef struct {
	cairo_gradient_pattern_t base;

	cairo_point_double_t center0;
	cairo_point_double_t center1;
	double		     radius0;
	double		     radius1;
} cairo_radial_gradient_pattern_t;

and these unions:

typedef union {
	cairo_gradient_pattern_t base;

	cairo_linear_gradient_pattern_t linear;
	cairo_radial_gradient_pattern_t radial;
} cairo_gradient_pattern_union_t;

typedef union {
	cairo_pattern_t base;

	cairo_solid_pattern_t		solid;
	cairo_surface_pattern_t		surface;
	cairo_gradient_pattern_union_t	gradient;
} cairo_gradient_pattern_union_t;


usage examples:

void
_cairo_int_function (cairo_pattern_t *pattern)
{
	cairo_pattern_union_t pu;

	_cairo_pattern_init_copy (&pu.base, pattern);

	....

	_cairo_pattern_fini (&pu.base);
}

cairo_surface_t *
_cairo_pattern_acquire_surface (cairo_pattern_t *pattern)
{
	switch (pattern->base.type) {
	case CAIRO_PATTERN_SOLID:
	return _acquire_solid ((cairo_solid_pattern_t *) pattern);

	....

	}
}
 
Suggestions?

I like it, and it shouldn't be too hard to get my patch converted to
this. I'll do that asap, if we decide that this is the way we want to
go.

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

-David