The current code results in trace lines with the source surface being
pushed on the stack two times instead of one:
s1 s1 //ARGB32 48 48 similar-image % s2
Instead of:
s1 //ARGB32 48 48 similar-image % s2
This greatly confuses later commands when the script was replayed,
causing traces for trivial GTK3 programs to be unplayable, usually
yielding the following error:
"invalid value (typically too big) for the size of the input (surface, pattern, etc.)"
Drop the duplicated entry from the trace line printed by the
cairo_surface_create_similar_image() override.
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=73580
Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com>
There are many more that can go, but these take the most bytes.
FC_CHARSET needs to go specially because I recently changed
its format in fontconfig. Ouch!
ARRAY_LENGTH macro is used in perf's cairo-perf.h, src's cairoint.h,
test's cairo-test.h and in some internal header files of util's
directory.So to maintain consistency ARRAY_SIZE is replaced with
ARRAY_LENGTH macro.
Signed-off-by: Ravi Nanjundappa <nravi.n@samsung.com>
Reviewed-by: Bryce Harrington <b.harrington@samsung.com>
CSI_STATUS_SUCCESS is defined as equivalent to CAIRO_STATUS_SUCCESS.
We should prefer the former when comparing against csi_status_t
variables, else we'll get a warning:
cairo-script-interpreter.c:637:23: warning: comparison between
‘csi_status_t’ and ‘enum _cairo_status’ [-Wenum-compare]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This quells the following warning:
warning: enumeration value ‘LZO’ not handled in switch [-Wswitch-enum]
The LZO enum value is defined and used elsewhere, even if lzo support
isn't available.
This situation might arise if cairo scripts were generated on one system
with lzo, and then replayed on a system without it. For now simply
error out if this occurs.
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
This error enum was added last September when JBIG2 support was added.
Support it as well in the tracing code. This fixes this warning:
trace.c:1544:5: warning: enumeration value
‘CAIRO_STATUS_JBIG2_GLOBAL_MISSING’ not handled in switch [-Wswitch]
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Recent updates (in the past couple of years) to firefox have exposed
numerous bugs in the way we emit the operands. A few off-by-ones,
missing surfaces and outright bugs all of which are intermixed into
producing a corrupt stack.
Reported-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In particular fixing up a couple of corner cases in emitting the right
instructions for scaled-fonts and patterns.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
But note we can only do the exchange if they do indeed match and
there are no other references (the objects are only on the stack).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Try using the lighter-weight LZO decompressor in an effort to speed up
replays (at the cost of making the bound traces slightly larger).
Presuming that with the slight increase in file size (from -1% to +10%),
the file data remains in the readahead buffer cache, replays see a
performance improvement of between 5-10%.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
s/CAIRO_GOBJECT_TYPE_HNT_METRICS/CAIRO_GOBJECT_TYPE_HINT_METRICS/
However, as we have already released the broken headers, we need to
preserve that mistake in case applications are already using. Since it
is just a #define, there is little associated cost with carrying both
the incorrect spelling and the corrected define.
The idiom (and expectation) for surface operators is that it leaves the
surface on the stack for the next operation. Also we need to hold onto a
surface reference for objects put onto the stack, yet for the
map-to-image return we did not own one.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Adjust the stack manipulation to avoid moving an unknown surface to
the dictionary.
Reported-by: Dongyeon Kim <dy5.kim@samsung.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
If we fail to resolve a particular pattern, try removing a few features
from the pattern and see if we can resolve that fallback and continue on
with the trace with a close approximation.
This is then behaves very similar as if the pattern requested a specific
font that was not available on the system and so was substituted.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Just emit a marker for when cairo_image_surface_get_data() is called on
a surface so that we have a breadcrumb for when the pixels are first
exported. (Though note that pointer may be kept around and used much
later.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As discussed, overloading the cairo_surface_t semantics to include
sources (i.e. read-only surfaces) was duplicating the definition of
cairo_pattern_t. So rather than introduce a new surface type with
pattern semantics, start along the thorny road of extensible pattern
types.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were calling the antialias close function from the unantialiased
paths - a function that operates on a completely different structure to
the one passed in.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Having spent the last dev cycle looking at how we could specialize the
compositors for various backends, we once again look for the
commonalities in order to reduce the duplication. In part this is
motivated by the idea that spans is a good interface for both the
existent GL backend and pixman, and so they deserve a dedicated
compositor. xcb/xlib target an identical rendering system and so they
should be using the same compositor, and it should be possible to run
that same compositor locally against pixman to generate reference tests.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
P.S. This brings massive upheaval (read breakage) I've tried delaying in
order to fix as many things as possible but now this one patch does far,
far, far too much. Apologies in advance for breaking your favourite
backend, but trust me in that the end result will be much better. :)
The cairo-missing library provides the functions which are needed in
order to correctly compile cairo (or its utilities) and which were not
found during configuration.
Fixes the build on MacOS X Lion, which failed because of collisons
between the cairo internal getline and strndup and those in libc:
cairo-analyse-trace.c:282: error: static declaration of ‘getline’ follows non-static declaration
/usr/include/stdio.h:449: error: previous declaration of ‘getline’ was here
cairo-analyse-trace.c:307: error: static declaration of ‘strndup’ follows non-static declaration
...
