Benjamin Otte pointed out the error of my ways that a clear on a
cairo_image_surface_create_for_data() was not working. This is because I
modified the image surface to skip clears when it knows the target data
has been cleared. This flag must be reset when the user interacts with
the surface, such as providing the initial surface data.
Hunting for a known bug in the xlib backend where it invalidly converts
an argb32 source to rgb24. However, this does not appear to be that bug,
but still a useful exercise nevertheless.
Commit 535bcaa1 moved pthread after win32 to fix mingw build
problems. However this breaks cygwin builds.
On cygwin HAVE_WINDOWS_H is defined but _WIN32 is not. This was
causing windows.h to be included which defines _WIN32. As a result the
win32 code in cairo-misc.c was being compiled but the win32 declaration
in cairint.h was not included.
Fix this by using _WIN32 to enable the win32 mutex functions since
_WIN32 is defined by mingw, visual C++, and winegcc, but not
cygwin. On cygwin, posix functions are preferred as it is a unix
emulation environment.
Gah! I had believed that the dst extents and the clip were correct to
enable unbounded fixup for the unbounded trapezoids. I was wrong, so I
need to requery the trapezoid extents. As this information is already
known, I should update the interface to pass along all relevant
information.
GCC uses a peculiar name for a real 128-bit integer on x86-64.
Speedups, xlib on a gm45
========================
poppler 41246.56 -> 35102.82: 1.18x speedup
swfdec-youtube 12623.01 -> 11936.79: 1.06x speedup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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!
Project lines that exceed the 16.16 limits onto the XFixedLine, as we know
that top/bottom must fit within the confines of the surface and so will be
less than 16 bits.
Sadly this is a run-on patch that also does:
1. Make FillTiled the default for new GCs.
2. Stores extend mode as opposed to repeat, and thereby cleaning up some
inconsistent code.
3. Remove the special casing for unbounded trapezoids, as it is redundant
with the polygon clipping.
4. Tidy the logic for deciding when to use the core protocol
(_categorize_composite_operation)
Implement cheap calculation of glyph extents to see whether we can discard
the clip region. This is effective around 50% of the time for firefox (and
makes the xtrace so much neater).
Now that we use polygon clipping, output geometry should no longer exceed
the 2^16 limits imposed by pixman. For the image backend, we now use spans
for stroking and for the xlib backend we have to double check the range on
the output trapezoids. In short, cairo should pass this test.
Fill a region using IN and a white source is a frequent reduction of a
complex clip (viz a path that covers the whole operation extents will be
reduced to a single rectangle), and we can simply discard the fill (as it
always has bounded semantics).
If the clip path is a simple box, then for many operations it is entirely
representation by the alteration of extents and so we can skip a few steps
during reconstruction.
Jeff Muizelaar reported a bug from his firefox builds that was causing a
double free during XCloseDisplay, and suggested it was related to
c0e01d9cd. Reviewing the cleanup, suggested that the cause may just be a
pair of missing parenthesis.
