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).
The master/slave terms are both inappropriate and inaccurate: the tee
surface replicates the rendering commands from a primary surface to
other surfaces.
This change is a mechanical search-and-replace.
The original "slim" symbol rewriting was added without any shred of a
set of performance evaluation, and mostly copy-pasted from a very early
version of pixman. Pixman itself never used them, and most C
libraries—like GLib and GTK—have dropped similar mechanisms over the
past 15 years, as linkers have improved considerably in the meantime.
Modern linkers provide functionality to avoid intra-library PLT jump
through flags like `-Bsymbolic-functions`; we should use that, instead,
and keep the code base more maintainable and debuggable.
A little history digging shows that we only ever had one caller of
_cairo_tee_surface_find_match. Commit 658cdc7c9a "Introduce
cairo_tee_surface_t" added this code to _cairo_surface_clone_similar():
if (src->type == CAIRO_SURFACE_TYPE_TEE) {
cairo_surface_t *match;
match = _cairo_tee_surface_find_match (src,
surface->backend,
content);
if (match != NULL)
src = match;
}
Then, two years later in 2011, commit af9fbd176b "Introduce a new compositor
architecture" removed _cairo_surface_clone_similar() and thus this code became
unused.
This commit drops this unused code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
_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>
A common requirement is the fast upload of pixel data. In order to
allocate the most appropriate image buffer, we need knowledge of the
destination. The most obvious example is that we could use a
shared-memory region for the image to avoid the transfer cost of
uploading the pixels to the X server. Similarly, gl, win32, quartz...
The other side of the equation is that for manual modification of a
remote surface, it would be more efficient if we can create a similar
image to reduce the transfer costs. This strategy is already followed
for the destination fallbacks and this merely exposes the same
capability for the application fallbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Step 1, fix the failings sighted recently by tracking clip-boxes as an
explicit property of the clipping and of composition.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Allow a backend to completely reimplement the Cairo API as it wants. The
goal is to pass operations to the native backends such as Quartz,
Direct2D, Qt, Skia, OpenVG with no overhead. And to permit complete
logging contexts, and whatever else the imagination holds. Perhaps to
experiment with double-paths?
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo_tee_surface_create copies the device transform from 'master' to
the new surface. This is wrong since all the cairo_surface_wrapper
functions apply master's device transform themselves.
Reviewed-by: Benjamin Otte <otte@redhat.com>
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
The device is a generic method for accessing the underlying interface
with the native graphics subsystem, typically the X connection or
perhaps the GL context. By exposing a cairo_device_t on a surface and
its various methods we enable finer control over interoperability with
external interactions of the device by applications. The use case in
mind is, for example, a multi-threaded gstreamer which needs to serialise
its own direct access to the device along with Cairo's across many
threads.
Secondly, the cairo_device_t is a unifying API for the mismash of
backend specific methods for controlling creation of surfaces with
explicit devices and a convenient hook for debugging and introspection.
The principal components of the API are the memory management of:
cairo_device_reference(),
cairo_device_finish() and
cairo_device_destroy();
along with a pair of routines for serialising interaction:
cairo_device_acquire() and
cairo_device_release()
and a method to flush any outstanding accesses:
cairo_device_flush().
The device for a particular surface may be retrieved using:
cairo_surface_get_device().
The device returned is owned by the surface.
As a simple step to ensure that we do not inadvertently modify (or at least
generate compiler warns if we try) user data, mark the incoming style
and matrices as constant.
Add a new surface type that multiplies it input onto several output
surfaces. The only limitation is that it requires a master surface that is
used whenever we need to query surface options, such as font options and
extents.
