[cairo] new pattern interface and OpenGL patch

[Thomas Hunger]

> Thomas Hunger wrote:
> I am not quite sure why you want to determine the extents by tesselating to
> traps first? An interpret_path should do the same thing but in a
> fraction of the time since tesselating is quite expensive compared to
> interpreting.
I think David's approach is correct. I guess this happens to the approach 
above: In the shading code which calculated sizes by interpreting and adding 
half of the line width, scaling by cairo_scale and then stroking returns a 
wrong bounding box because line_width in the gstate is not scaled by the 
matrix before added to the bounding box returned from interpret path. 
But this I resolved by scaling the line_width (one in x, one in y direction) 
before adding using the ctm. The problem then was that different caps and 
joins returned the same bounding box although they obviously did not cover 
the same area. (I could have seen this before:
http://keithp.com/~keithp/talks/xr_ols2003/html/xr_ols2003.html#fig:caps_joins
)
This is only a guess, is it correct?

> My answer:
> Yes, you're right tesselation is much more expensive but it's also much
> easier to get accurate. Exact regions, independent of stroke width and
> such. I thought there might be problems with interpreting when cairo
> supports dashed bezier curves and variable stroke width. When it comes
> to performance the region calculations for the create_pattern function
> are even faster than interpreting as we can calculate the region from
> the already tesselated traps. The public API functions are of course a
> bit slower as they need to actually tesselate the path on its own (but
> we could cache the traps to remove this performance penalty, if
> necessary). My tests have also proven that this performance penalty is
> almost significant compared to the actual rendering time, even for the
> OpenGL backend.