On OpenBSD the convention is to not use symlinks from
unversioned library names to versioned library names.
This breaks cairo-trace because it looks for cairo-trace.so
explicitly, but on OpenBSD only cairo-trace.so.0.0 is
installed.
The right thing to do is probably to source the cairo-trace.la
file and look for a file name there somehow. Instead this commit
just looks for a likely looking file or symlink in the install
directory.
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.
This appears to be the simplest mechanism to build libglew at the moment -
should a system copy be unavailable. Fortunately libglew is now distributed
under a permissive licence.
If you want to pass 'make -C src check' you have to use the system copy,
or spend quite a bit of time cairo-fying libglew.
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.
There you go Joonas, I don't always ignore your suggestions! This is
simple patch to allow the user to disable symbol loops in case the
auto-detection fails on some obscure (perhaps OpenBSD) platform. Or in
case the user really wants to trim a few bytes from a library only used
during tracing!
Some environments may be broken beyond our capabilities to detect, or
maybe the user is just insane and doesn't want to build my nice shiny
cairo-trace. Whatever, give them the option to choose:
$ ./configure --disable-trace
In order to get a baseline for win32 performance testing, always create a
font so that the trace can be replayed. Not ideal, but I feel this the
pragmatic solution for judging the performance differentials before I can
work out a better solution for loading typ42 fonts.
In order to enable replay of traces on machines that do not use FreeType
as the native font system, we need to convert a type42 font into something
similar. Currently the fallback is just to select a font with the same
name - this ignores weight and slant, and many other details.
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.
A very simple surface that produces a hierarchical DAG in a simple XML
format. It is intended to be used whilst debugging, for example with the
automatic regression finding tools of cairo-sphinx, and with test suites
that just want to verify that their code made a particular Cairo call.
sphinx is an alternate version of the current cairo-test-trace. It's
purpose is to replay a live application (which may just be a replay of a
trace) against a backend and its reference. The improvement over the
original cairo-test-trace is that the reference backend may be from an
older version of cairo.
This is a simple variation on cairo-trace that wraps records the last 16
contexts by wrapping the target surface inside a tee surface, along with a
meta/recording surface. Then on receipt of a SIGUSR1, those last 16
contexts are played via a script-surface into /tmp/fdr.trace.
Mostly proof-of-concept, it seems to be causing a number of rendering
glitches whilst testing with firefox -- otherwise, it seems to works.
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.
Kerning is quite frequent, that is to apply a horizontal but no vertical
offset to a glyph. For instance by discarding the vertical coordinate
where it remains the same and only encoding the horizontal offset we
reduce the file size by ~12.5% when tracing poppler.
We refactor the surface fallbacks to convert full strokes and fills to the
intermediate polygon representation (as opposed to before where we
returned the trapezoidal representation). This allow greater flexibility
to choose how then to rasterize the polygon. Where possible we use the
local spans rasteriser for its increased performance, but still have the
option to use the tessellator instead (for example, with the current
Render protocol which does not yet have a polygon image).
In order to accommodate this, the spans interface is tweaked to accept
whole polygons instead of a path and the tessellator is tweaked for speed.
Performance Impact
==================
...
Still measuring, expecting some severe regressions.
...
