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>
During replay we want to handle recording surfaces specially, and not
redirect the creation of those to the target surface. This is similar to
the need to keep image surfaces as images during replay.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
cairo-xcb's acquire_source_image implementation will attach the image it returns
as a snapshot to the xcb surface. cairo_surface_mark_dirty_rectangle asserts
that the surface doesn't have any snapshots attached. cairo-trace will emit the
surface to the trace when it was marked dirty by drawing it to an image surface.
The combination of these three things caused a failed assertion when cairo-trace
was used on something which uses xcb/Xlib and which uses mark_dirty.
I found this with firefox and xlib-xcb.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes all warnings that looked like this:
warning: enumeration value 'CAIRO_STATUS_DEVICE_FINISHED' not handled in switch
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is a common format used by framebuffers to drive 10bpc displays
and is often hardware accelerated by XRender with underlying support
from pixman's x2r10g10b10 format (which provides coercion paths for
fallbacks).
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
By emitting an empty function name when it it impossible to perform
the lookup, we can get rid of the warning:
trace.c:3714: warning: unused variable ‘symbol’
Additionally, this makes the syntax (or, rather, the parameter count)
for write-to-png-stream the same on every configuration.
Compiler warning saves the day!
trace.c: In function ‘_emit_font_options’:
trace.c:2973:20: warning: comparison between ‘cairo_hint_style_t’ and
‘enum _cairo_hint_metrics’
A genuine bug, thanks gcc!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Add the mesh pattern type and an error status to be used to report an
incorrect construction of the pattern.
Update the backends to make them ready to handle the new pattern type,
even if it cannot be created yet.
What we want to use is size_t, but we don't want the implied POSIX
dependency. However, POSIX does say that size_t is an unsigned integer
that is no longer than a long, so it would appear safe to use an
unsigned long as a replacement. Safer at least than unsigned int.
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.
trace.c:1154: warning: ‘_has_font_face_id’ defined but not used
trace.c:1196: warning: ‘_get_pattern_id’ defined but not used
trace.c:1870: warning: ‘_emit_font_face’ defined but not used
trace.c:1882: warning: ‘_emit_scaled_font’ defined but not used
Trace files were using host-endian to represent the length of
compressed data, making the trace format not portable.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
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.
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.
Enable "ld_preload" (DYLD_INSERT_LIBRARIES + DYLD_FORCE_FLAT_NAMESPACE)
and build cairo-trace as a library instead of a module to make it
work also on MacOS X.
Replaying a meta surface can be achieved by using it as a source for a
cairo_paint() so exporting a separate API is unnecesary and confusing.
So after consulting Chris and Carl, we decided to remove the function
again.
On OpenBSD libc doesn't provide pthread stubs like glibc on Linux
or newer libcs from FreeBSD. However libX11 does provide a stubs
for a subset of the pthread functions (formerly in libXThrStub,
now moved into libX11 proper), but pthread_key_delete() is not
one of the stubbed ones. So, on OpenBSD cairo's non-linking of
libpthread accidentally works as long as the xlib-surface is enabled,
which is nearly always the case.
This patch makes trace.c stand at the same precipice as cairo itself
by reverting to only a subset of the pthreads functions stubbed by
libX11.
The autoconf shipping with OpenBSD 4.5 converts sizeof(void*)
to SIZEOF_VOID__ rather than SIZEOF_VOID_P. Work around that
by defining SIZEOF_VOID_P if required.
On various configurations of Solaris cairo-trace likes to trace
internal calls to the API from within cairo and cairo-trace itself. On
Linux the slim_hidden_proto stuff avoids this by name mangling and
symbol alias magic, but on Solaris that doesn't work so we're left
with either no hidden symbols at all or using normal ELF hidden symbol
attributes, but neither of those prevent internal calls to cairo from
being traced of course.
This commit provides a per-thread entry/exit trace counter for use
when we can't use name mangling to hide internal API calls. As a
side-effect it may hide actual client API calls from callback
functions called by cairo, but such use cases ought to be rare.
Use pthread_once() at cairo API entry points to initialise the library
if required. This side steps the issues with the __constructor__
attribute vs _init()/_fini() on Solaris and different tracer/tracee
runtimes which result in the constructors not being run in
cairo-trace.so.
If the tracer encounters an unknown enum value it
ought not to crash. Theis patch replaces the idiom
of looking up a name for an enumerated value directly
from a table by a switch statement. As a bonus we get
warnings from the compiler when the enums are updated
in cairo.
If the tracer's object stack underflows we want to
know about is as soon as possible. This patch adds
checks against the stack overflowing and aborts the
program with an object stack dump if it does.
Support non-Linux systems which don't have a /proc/self/cmdline
by transferring the application name given to cairo-trace via
an environment variable CAIRO_TRACE_PROG_NAME.
cairo_script_context_t is an encapsulation object for interfacing with the
output - multiple surfaces can share the same context, meaning that they
write to the same destination file/stream.
Larry Ewing hit a bug in cairo-trace whereby it tried to create a similar
surface referencing an undefined object. This fix checks whether the
object has yet to be defined, and if not issues an index in order to copy
the appropriate operand from the stack.
font expects the dictionary to be constructed on the stack for its use, so
close it. (I missed the closing '>>' when switching between dictionary
constructors.)