This test does various operations with a clear source surface with
various content types.
The idea is to make sure optimizations done when surface->is_clear ==
TRUE only happen in the proper cases.
Jeff reported a regression found by Mozilla whereby a uniform gradient
was not being premultiplied on conversion to a solid pattern.
https://bugzilla.mozilla.org/show_bug.cgi?id=539165
[Bug 539165] gradients with a single stop do not have their color
multiplied by the alpha.
Whilst investigating:
Bug 31788: SVG <line> with y1 == y2 and both with fractional
part don't render
https://bugs.webkit.org/show_bug.cgi?id=31788
I found that it can be reduced to a no-op clip following a no-op stroke
or fill. These conditions are exercised here and are shown to be a bug
introduced in the 1.9.x development series.
Compositing of alpha-only sources is not throughly tested and
as a consequence the misbehaviour of some backends is not
shown by the test suite.
[ickle: Added XFAILs for pdf, ps, svg.]
This test fills a slightly rotated surface slightly above the 0 line.
This hits some corner cases in the XRenderComposite path.
I discovered these issues while playing with video rendering onto the
canvas in HTML5 (both Webkit and Mozilla have this problem).
I used CAIRO_ANTIALIAS_NONE and a single-color source in the test to get
rid of aliasing issues in the output images. This makes some issues
slightly less visible, but still fails for all of them. If you want to
get a clearer view, disable it and use romedalen.png instead - it has
the same size as the red surface.
(At least) 3 bugs are at work here:
- if _line_exceeds_16_16() triggers for the reference point, the
source surface will be misaligned.
- the intel driver seems to have an off-by-one bug on my i945 when
positioning the source surface, causing black seams at the top
(not visible in the test unless using romedalen.png) and on the left
of the image.
- My Xvfb fails completely in picture up/download in the xlib-fallback
path.
Hunting for a known bug in the xlib backend where it invalidly converts
an argb32 source to rgb24. However, this does not appear to be that bug,
but still a useful exercise nevertheless.
Add a couple of tests to exercise a bug that Joonas spotted that I had
introduced with the clip-reduction scheme - namely that I had
incorrectly removed the clip on unbounded operations.
Soeren was the first to report a clipping regression in the xlib backend
with strokes, and provided a test case to exercise the bug. This is an
extension of his test to provide coverage of different clipping and
stroking methods.
This is a simple test that broke with the determination of rectilinearity
during path construction. I forgot the implicit close on fill and so the
ignored the final diagonal edge and failed to draw the triangle.
We refactor the surface fallbacks to convert full strokes and fills to the
intermediate polygon representation (as opposed to before where we
returned the trapezoidal representation). This allow greater flexibility
to choose how then to rasterize the polygon. Where possible we use the
local spans rasteriser for its increased performance, but still have the
option to use the tessellator instead (for example, with the current
Render protocol which does not yet have a polygon image).
In order to accommodate this, the spans interface is tweaked to accept
whole polygons instead of a path and the tessellator is tweaked for speed.
Performance Impact
==================
...
Still measuring, expecting some severe regressions.
...
Andrea Canciani (ranma42) found another instance of my broken 'degenerate'
curve-to as line-to optimisation. All I can say is when I do something
wrong, at least I'm consistent!
This test case highlights the bug in the rel-curve-to path.
The stroker code is liable to wedge when passed
dash patterns which don't advance the dash offset
due to limited precision arithmetic. This test
attempts to hit all the places in the stroker where
that can happen.
Reported on the cairo mailing list by Hans Breuer:
http://lists.cairographics.org/archives/cairo/2009-June/017506.html
Andrea Canciani (ranma42) pointed out a second bug in the curve-to as
line-to optimisation, that is a curve starting and finishing on the same
point is not necessarily degenerate. This test case exercises 5 different
curves that start and end on the same point.
This test anticipates a future optimization, (already pushed
upstream but not pulled yet), with a buggy implementation
of replacing curve_to with line_to.
Handling clip as part of the surface state, as opposed to being part of
the operation state, is cumbersome and a hindrance to providing true proxy
surface support. For example, the clip must be copied from the surface
onto the fallback image, but this was forgotten causing undue hassle in
each backend. Another example is the contortion the meta surface
endures to ensure the clip is correctly recorded. By contrast passing the
clip along with the operation is quite simple and enables us to write
generic handlers for providing surface wrappers. (And in the future, we
should be able to write more esoteric wrappers, e.g. automatic 2x FSAA,
trivially.)
In brief, instead of the surface automatically applying the clip before
calling the backend, the backend can call into a generic helper to apply
clipping. For raster surfaces, clip regions are handled automatically as
part of the composite interface. For vector surfaces, a clip helper is
introduced to replay and callback into an intersect_clip_path() function
as necessary.
Whilst this is not primarily a performance related change (the change
should just move the computation of the clip from the moment it is applied
by the user to the moment it is required by the backend), it is important
to track any potential regression:
ppc:
Speedups
========
image-rgba evolution-20090607-0 1026085.22 0.18% -> 672972.07 0.77%: 1.52x speedup
▌
image-rgba evolution-20090618-0 680579.98 0.12% -> 573237.66 0.16%: 1.19x speedup
▎
image-rgba swfdec-fill-rate-4xaa-0 460296.92 0.36% -> 407464.63 0.42%: 1.13x speedup
▏
image-rgba swfdec-fill-rate-2xaa-0 128431.95 0.47% -> 115051.86 0.42%: 1.12x speedup
▏
Slowdowns
=========
image-rgba firefox-periodic-table-0 56837.61 0.78% -> 66055.17 3.20%: 1.09x slowdown
▏
Test case for:
Bug 22441 -- Unexpected shift with push_group and pop_group
https://bugs.freedesktop.org/show_bug.cgi?id=22441
This is a test that demonstrates the error in the pdf backend when using
groups on surfaces with non-integer sizes. In order to create such a
surface, we need to update the boilerplate to use doubles instead of
integers when specifying the surface size.
Quite an expensive test that converts an image into a distorted array of
glyphs, using a perspective transformation taking the intensity of the
pixel as depth. This generates a pretty picture and many overlapping
glyphs.
Add a variation of test-fallback-surface that forces the use of a 16-bit
pixman format code instead of the standard 32-bit types. This creates an
image surface akin to the fallbacks used with low bit-depth xservers.
Eliminate the need for a runtime test on the sizeof the private structures
by performing the check at compile time. This was provoked by Ginn Chenn
noting that the test was including a private header.
Jeff Muizelaar found a regression in commit 005436 and submitted this
little test to exercise it. The essence of the bug appears to be wrt to
the product of the CTM and device transform matrices.
