A push/pop is an implicit save/restore, so a clip applied inside the
group is temporary, whereas a clip applied outside affects both the
geometry inside *and* the application of the group when painted. So
reset the clip afterwards to get the desired behaviour.
We were exposing the actual value of CAIRO_FORMAT_INVALID
through API functions already, so it makes sense to just
go ahead and put it in the cairo_format_t enum.
Franz Schmid reported a regression in 1.9.6 when downscaling
and using EXTEND_REPEAT for an image surface pattern. This
patch adds such tests for every extend mode.
The clip-group-shapes-* tests check that it doesn't
matter whether the clip path is set before or after
pushing a group using specific types of clip paths
(aligned/unaligned rectangles and general paths.)
The test was returning a cairo_status_t, but should be returning
a cairo_test_status_t instead. When the test failed it was
being reported as having crashed, rather than merely failed,
because the enum value of CAIRO_TEST_CRASHED happened to be
same as the cairo_status_t value of the cairo context at
the end of the failing test.
It was observed that we never actually test the condition that the
gradient is only defined for a portion of its range, i.e. the starting
offset is >0 and the ending offset is <0. By definition the colour
between 0 and start offset is the start color, so check that this
behaviour is followed by all backends.
Another bug identified by Jeff Muizelaar was that the bounds for a
zero-length (i.e. it started and stopped at the same point) were
miscomputed. This test case exercises that bug.
Note: I believe the output is wrong here when padding a zero-length
gradient. On the left it should be red, and on the right it should be
blue.
Jeff Muizelaar found a bug in _cairo_clip_init_copy() which was not
correctly propagating the all-clipped status when an empty clip was
saved in the gstate. This test case exercises that bug.
Still an experimental backend, it's now a little too late to stabilise
for 1.10, but this should represent a major step forward in its feature
set and an attempt to catch up with all the bug fixes that have been
performed on xlib. Notably not tested yet (and expected to be broken)
are mixed-endian connections and low bitdepth servers (the dithering
support has not been copied over for instance). However, it seems robust
enough for daily use...
Of particular note in this update is that the xcb surface is now capable
of subverting the xlib surface through the ./configure --enable-xlib-xcb
option. This replaces the xlib surface with a proxy that forwards all
operations to an equivalent xcb surface whilst preserving the cairo-xlib
API that is required for compatibility with the existing applications,
for instance GTK+ and Mozilla. Also you can experiment with enabling a
DRM bypass, though you need to be extremely foolhardy to do so.
Write a dedicated compositor for pixman so that we avoid the
middle-layer syndrome of surface-fallback. The major upshot of this
rewrite is that the image surface is now several times quicker for glyph
compositing, which dramatically improves performance for text rendering
by firefox and friends. It also uses a couple of the new scan
convertors, such as the rectangular scan converter for rectilinear
paths.
Speedups
========
image-rgba firefox-talos-gfx-0 342050.17 (342155.88 0.02%) -> 69412.44 (69702.90 0.21%): 4.93x speedup
███▉
image-rgba vim-0 97518.13 (97696.23 1.21%) -> 30712.63 (31238.65 0.85%): 3.18x speedup
██▏
image-rgba evolution-0 69927.77 (110261.08 19.84%) -> 24430.05 (25368.85 1.89%): 2.86x speedup
█▉
image-rgba poppler-0 41452.61 (41547.03 2.51%) -> 21195.52 (21656.85 1.08%): 1.96x speedup
█
image-rgba firefox-planet-gnome-0 217512.61 (217636.80 0.06%) -> 123341.02 (123641.94 0.12%): 1.76x speedup
▊
image-rgba swfdec-youtube-0 41302.71 (41373.60 0.11%) -> 31343.93 (31488.87 0.23%): 1.32x speedup
▍
image-rgba swfdec-giant-steps-0 20699.54 (20739.52 0.10%) -> 17360.19 (17375.51 0.04%): 1.19x speedup
▎
image-rgba gvim-0 167837.47 (168027.68 0.51%) -> 151105.94 (151635.85 0.18%): 1.11x speedup
▏
image-rgba firefox-talos-svg-0 375273.43 (388250.94 1.60%) -> 356846.09 (370370.08 1.86%): 1.05x speedup
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).
