To avoid any possibility of uninitialized memory.
The exceptions are:
- where the allocation is immediately overwritten by a memcpy or struct copy.
- arrays of structs to avoid any performance impact (except when the
array is returned by the public API).
_cairo_malloc(0) always returns NULL, but has not been used
consistently. This patch replaces many calls to malloc() with
_cairo_malloc().
Fixes: fdo# 101547
CVE: CVE-2017-9814 Heap buffer overflow at cairo-truetype-subset.c:1299
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Invoking cairo_surface_mark_dirty () on an observer surface would
cause it to print debugging output to stdout.
Reviewed-by: Andrea Canciani <ranma42@gmail.com>
Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=95227
This adds a number of items to the documentation for which code docs
exist, and also adds sections for cairo-skia and cairo-surface-observer.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=48784
Signed-off-by: Bryce Harrington <b.harrington@samsung.com>
In many places Cairo maps/unmaps surfaces to perform operations on the
raw image, but it doesn't care about the format being invalid. All of
these are appropriate users of _cairo_surface_map_to_image().
GCC complains that:
cairo-surface-observer.c:289:26: warning: ignoring return value of
'cairo_device_acquire', declared with attribute warn_unused_result
[-Wunused-result]
Explain why it's safe to ignore it in a comment.
Making cairo_surface_observer_print() and
cairo_device_observer_print() return the status of the observer or of
the stream makes it possible to correctly track what kind of error
happens if the print is not successful.
This makes the functions more consistent with existing API with a
similar signature like cairo_surface_write_to_png_stream().
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>
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. :)
Returning a void value is an error on suncc and causes a warning on msvc:
cairo-surface-observer.c(1273) : warning C4098:
'_cairo_surface_observer_release_source_image' : 'void' function
returning a value
round() is not available on win32 and causes the linking to fail with:
cairo-surface-observer.obj : error LNK2019: unresolved external symbol
round referenced in function percent
Add the cairo_time_t type (currently based on cairo_uint64_t) and use
it in cairo-observer and in the perf suite.
Fixes the build on MacOS X (for the src/ subdir) and Win32, whch
failed because they don't provide clock_gettime:
cairo-surface-observer.c:629: error: implicit declaration of function 'clock_gettime'
cairo-surface-observer.c:629: warning: nested extern declaration of 'clock_gettime'
cairo-surface-observer.c:629: error: 'CLOCK_MONOTONIC' undeclared (first use in this function)
...
The existing API only described the method to be used for performing
rasterisation and unlike other API provided no opportunity for the user
to give a hint as to how to trade off performance against speed. So in
order to no be overly prescriptive, we extend the NONE/GRAY/SUBPIXEL
methods with FAST/GOOD/BEST hints and leave the backend to decide how
best to achieve those goals.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
In order for this to be effective on small system we also need to
disable the recording of the long traces which exhaust all memory...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We can use the elapsed time of the indiividual operations to profile the
synchronous throughput of a trace and eliminate all replay overhead. At
the cost of running the trace synchronously of course.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
We were misclassifying rectilinear paths as aligned strokes, which is
bogus until we analyse the offset path.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As we want to record the exact command pass to us, we want to bypass any
further optimisations that the surface mid-layer might perform before
passing the operation to the recording surface.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
The immediate use of this is to print out the slowest operation of each
type in a replayable manner. A continuing demonstration of how we may
analyse traces...
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Seeing the relative amounts of time spent in each operation and the
slowest one of each, gives further insight into the peculiarities of a
trace. And hopefully point out areas of improvement.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
A clip with only a single path or can be reduced to a single polygon are
easier to handle than a clip containing a mixture of paths (typically
ANTIALIAS_NONE vs ANTIALIAS_DEFAULT).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
As these tend to be the quickest, and putting them first keeps the reports
are in an estimated fast->slow order.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Another logging passthrough surface that records the style of operations
performed trying to categorise what is slow/fast/important.
In combination with perf/cairo-analyse-trace it is very useful for
understanding what a trace does. The next steps for this tool would be
to identify the slow operations that the trace does. Baby steps.
This should be generally useful in similar situations outside of perf/
and should be extensible to become an online performance probe.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
