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.
In order to catch infinite loops whilst replaying and converting vector
surfaces to images (via external renderers) we need to also install
alarms around the calls to finish() and get_image().
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.
Looks like ghostscript has a similar buggy optimization like we
just fixed in cairo. I'm just waiting on a new bugzilla account
from bugs.ghostscript.com after which I plan to report the bug
there.
This test anticipates a future optimization, (already pushed
upstream but not pulled yet), with a buggy implementation
of replacing curve_to with line_to.
user-font-rescale copied unitialized values from the widths array into
the desired array. Although these corresponded to unused glyphs and so
were never used during the rendering, the values may have been illegal
causing FPE as they were copied.
Use the DRM interface to h/w accelerate composition on image surfaces.
The purpose of the backend is simply to explore what such a hardware
interface might look like and what benefits we might expect. The
use case that might justify writing such custom backends are embedded
devices running a drm compositor like wayland - which would, for example,
allow one to write applications that seamlessly integrated accelerated,
dynamic, high quality 2D graphics using Cairo with advanced interaction
(e.g. smooth animations in the UI) driven by a clutter framework...
In this first step we introduce the fundamental wrapping of GEM for intel
and radeon chipsets, and, for comparison, gallium. No acceleration, all
we do is use buffer objects (that is use the kernel memory manager) to
allocate images and simply use the fallback mechanism. This provides a
suitable base to start writing chip specific drivers.
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
▏
After looking at backend specific images, check against the base image
reference. This is useful to fallback surfaces like xlib-fallback, which
should look closer to the image backend than the xlib backend.
Based on the work by Øyvind Kolås and Pierre Tardy -- many thanks to
Pierre for pushing this backend for inclusion as well as testing and
reviewing my initial patch. And many more thanks to pippin for writing the
backend in the first place!
Hacked and chopped by myself into a suitable basis for a backend. Quite a
few issues remain open, but would seem to be ready for testing on suitable
hardware.
Instead of tagging the sources, which is insensitive to changes, track the
known failure modes by recording the current fail as an xfail.png
reference. (We also introduce a new.png to track a fresh error, so that
they are not lost in the noise of the old XFAILs and hopefully do not
cause everyone to fret).
As we have removed the XFAIL tagging we find, surprise surprise, that some
tests are now working -- so review all the reference images (as also some
.ref.png now should be .xfail.png).
Note: I've only checked image,pdf,ps,svg. The test surfaces report some
failures that probably need to addressed in source. I've not correct the
changes for win32 and quartz. Nor fixed up the experimental backends.
When converting a grid pixel area into the range [0,255] the
GRID_AREA_TO_ALPHA() macro would truncate extra bits off the result
rather than rounding. This could cause seams between abutting
collinear edges of separately rendered polygons even when the
coordinates of the abutting edges were the same.
Reported by Soeren Sandmann on the cairo mailing list:
http://lists.cairographics.org/archives/cairo/2009-May/017043.html
By moving the backend target definition out of the massive amlagamated
block in cairo-boilerplate.c and into each of the
cairo-boilerplate-backend.c, we make it much easier to add new targets as
the information need only be entered in a single file and not scattered
across three. However, updating the target interface means trawling across
all the files -- except given that I found it difficult maintaining the
single massive array I do not see this as an increase in the maintenance
burden.
The meta-surface is a vital tool to record a trace of drawing commands
in-memory. As such it is used throughout cairo.
The value of such a surface is immediately obvious and should be
applicable for many applications. The first such case is by
cairo-test-trace which wants to record the entire graph of drawing commands
that affect a surface in the event of a failure.
Requires hooking into test-meta-surface currently. Export meta-surface!
The idea is that on detection of an error, we can reconstruct a minimal
trace from the meta-surface. The first step is to simply dump the trace
for the failing meta-surface. Later, we should automatically minimise
this further.
