Carefully handle subsurfaces of a recording surface through the analysis
and paginated surfaces so that we can generate a native pattern for the
vector backends, demonstrated by the PostScript backend.
Nothing remarkable, just a lot of bookkeeping to track the wrapped
surface types and to apply the correct offsets when generating the
subsurface pattern.
After a renewed discussion, it was pointed out that the API in Cairo was
not restrictive and by using doubles we would be consisted with the rest
of the API. Thus prompting the name change to
cairo_surface_create_for_rectangle()
similar to cairo_rectangle().
And document the public API.
Use a similar surface to create an equivalent backing surface for
any backend, thus enabling the test to run against any target.
The comment about forcing fallbacks has long since been false.
The issue being that as the on-stack data is being referenced via a
zero-copy snapshot outside of the functions scope as the surface is only
finished and the source written long after the draw() returns. The
correct procedure is that the user must call cairo_surface_finish()
prior to any surface becoming inaccessible. In this case, this triggers
the snapshot to preserve a copy of the data whilst it is still valid.
I updated the Free Software Foundation address using the following script.
for i in $(git grep Temple | cut -d: -f1 )
do
sed -e 's/59 Temple Place[, -]* Suite 330, Boston, MA *02111-1307[, ]* USA/51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA/' -i "$i"
done
Fixes http://bugs.freedesktop.org/show_bug.cgi?id=21356
cu found a bug when using clipping and fills with the image backend, but
it turns out to be the lost sign bug afflicting everything...
To trigger the bug requires evaluating the clip surface prior to using
in with _cairo_clip_combine_with_surface(). Which is taken along a
particular path when using a clip mask with non-pixel geometry on image,
but more easily hit by the fallback code.
Reported-by: <cairouser@yahoo.com>
This should exercise a bug found by Jeff Muizelaar that
cairo-surface-clipper was mistakenly thinking that clip operations on a
second context was a no-op as the topmost clip path matched that of the
previous context.
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
