A surface will have the chance to use span rendering at cairo_fill()
time by creating a renderer for a specific combination of
pattern/dst/op before the path is scan converted. The protocol is to
first call check_span_renderer() to see if the surface wants to render
with spans and then later call create_span_renderer() to create the
renderer for real once the extents of the path are known.
No backends have an implementation yet.
A cairo_span_renderer_t implementation can be provided by a surface if
it wants to render paths as horizontal spans of the alpha component of
a mask. Its job is to composite a source pattern to the destination
surface when given spans of alpha coverage for a row while taking care
of backend specific clipping.
A cairo_scan_converter_t takes edges of a flattened path and generates
spans for a span renderer to render.
A cairo_composite_rectangles_t contains the coordinates of rectangular
windows into each of the source pattern, mask, clip and destination
surface containing the pixels that will combine in a compositing
operation. The idea is to have a uniform way to represent all the
translations involved rather than overloading parameters like src_x/y,
dst_x/y, etc., sometimes with different incompatible meanings across
functions.
We want to hit the current fast paths for rendering axis aligned
rectilinear paths rather than spans, and for that we need to be able
to identify regional paths.
Since git 1.6 the plumbing commands aren't installed in the user's
path by default. This patch fixes cairo-perf-diff to find the
git-sh-setup command from git's lib dir.
These tests look at the differences in code paths
hit by filling paths that are rectilinear (or not) and
pixel aligned (or not) with the even-odd and non-zero
fill rules. The paths are not simple, so they don't
hit the special case quad/triangle tessellator.
We don't have one just for this purpose. The only other
path with many intersections that gets actually rendered is zrusin-another,
but that might be sped up in the future (say by identifying
collinearities up front or something like that.)
Repeat should be handled using MOD instead of '%' so that negative numbers
are handled as expected. E.g. -1 mod 600 = 599, not 495 as the '%' operator
gives. This was causing https://bugzilla.mozilla.org/show_bug.cgi?id=466258
Patch from Robert O'Callahan
Otherwise if underlying glitz drawable has an alpha channel, glitz_set_rectangles
will set its alpha channel to specified value instead of opaque one and effects following
composite operations since glitz draws to attached drawable then copies its content to
the dst surface. With this commit, three test cases such as operator, operator-alpha and
unbounded-operator passes now.
The nature of the joins depends critically upon whether the joint is
clockwise or counter-clockwise, so extend the basic caps-joins test to
exercise both conditions i.e. repeat the test under a reflection.
Use unsigned long in the first place to prevent compiler from
expanding signed bit to all upper bits. e.g, a alpha mask 0xff0000
will expand to 0xffffffffff00000 on 64 bit platform which is not
what we expected.
Clone similar open-coded various image surface functions and failed to
clone a sub-region resulting in failures for mask-transformed-* and
large-source.
The attached patch makes the SDL tests compile under Mac OS X. The
problem is:
1) that <SDL_main.h> should be included in files that define the main
function for SDL Mac OS X programs (this is not true with the upcoming
SDL 1.3 release).
2) that -lSDLmain, because it is statically linked, needs the Cocoa
framework in the LDADD of the main program. Again, 1.3 will not require
this.
Ensure we do not loop forever trying to minimise the error between the
pixman and cairo matrices - for instance when the FPU is not running at
full precision.
Adrian Johnson reported that cygwin complained about the use of the void *
within feof() as it was using a macro and attempted a to deference the
void*...
As suggested on the list, this splits the cairo-boilerplate-glitz.c
file in three separate files, one for each backend. Furthermore,
it fixes a few problems in compilation of the AGL backend test harness.
When computing the bounds of the clip path, we care more for a fast result
than absolute precision as the extents are only used as a guide to trim
the future operations. So computing the extents of the path suffices.
