Having added a specialised scan converter on the premise that it should
be better at handling rounded rectangles, ensure that they are indeed
rendered correctly.
Enable origin tracking by default for make check-valgrind. This is
slower and consumes more memory than regular valgrind, but the
additional information provided about the source of the uninitialised
data is often invaluable.
A subsurface is a region of another surface that may be used either to
restrict the writable area of a context or the readable extents of a
source. Whilst writing, access to the exterior of the subsurface is
prevented via clipping and when used as a source reads from the exterior
of the subsurface are governed via the extend mechanism of the pattern.
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.
Real applications that control their Drawable externally to Cairo are
'disadvantaged' by cairo-perf-trace when it creates a similar surface
for each new instance of the same Drawable. The difficulty in
maintaining one perf surface for every application surface is that the
traces do not track lifetimes for the application surfaces, so we would
just accumulate stale surfaces. The surface cache takes a different
approach and returns the same surface for each active Drawable, and
maintains a hold-over of the MRU 16 surfaces. This achieves 60-80% hit
rate with firefox, which is probably as good as can be expected.
Obviously for double-buffered applications we only every draw to freshly
created surfaces (and Gtk+ bypasses cairo to do the final copy -- the
ideal application would just use a push-group for double buffering, in
which case we would capture and replay the entire expose event).
To enable use of the surface cache whilst replaying use -c:
./cairo-perf-trace -c firefox-talos-gfx
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.
A recent optimisation has added a flag to the image
surface which is used to track whether the surface
is clear or not. This makes it imperative that clients
call cairo_surface_mark_dirty() if they use cairo to
allocate their pixel buffers and then proceed to
initialize them without telling cairo about it.
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.
The infinite loop problem in _cairo_stroker_dash_start is solved by
commit ee02f3484899527380df94c00f40da87f41660ea, so hitting that
problem is not possible anymore and dash-infinite stroke always
hit the memory intensive loops.
This reverts commit 29432d3d32.
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.
Otherwise, it was disrupting my attempts to release a snapshot, (since
it doesn't respect CAIRO_TEST_TARGET=" " and not run like most of the
tests do).
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
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.
Now that we use polygon clipping, output geometry should no longer exceed
the 2^16 limits imposed by pixman. For the image backend, we now use spans
for stroking and for the xlib backend we have to double check the range on
the output trapezoids. In short, cairo should pass this test.
If a backend fails in exactly the same way as the image, then we can
safely assume that the failure is systematic and not an error in the
backend, so change the result to XFAIL.
Do not blindly assume that we managed to construct a valid scaled-font
before attempting to dereference the FT_Face. Consider a machine with
no fonts which is substituting twin...
This test is annoying enough as it is what with it wedging the
test suite and all. There's no reason why it should DOS the
running box as well by sitting in a loop allocating like mad.
