| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Various minor tweaks to convert asserts into error returns and to
improve error checking on intermediate surfaces.
|
|
The draw_pattern() function assumed the incoming surface
was clear, but it's not. Explicitly clear the surface first.
|
|
Include a translucent region in the source that exercises the xlib bug
that I'm trying to fix. Hmm.
|
|
Damian Frank noted
[http://lists.cairographics.org/archives/cairo/2009-May/017095.html]
a performance problem with an older XServer with an
unaccelerated composite - similar problems will be seen with non-XRender
servers which will trigger extraneous fallbacks. The problem he found was
that painting an ARGB32 image onto an RGB24 destination window (using
SOURCE) was going via the RENDER protocol and not core. He was able to
demonstrate that this could be worked around by declaring the pixel data as
an RGB24 image. The issue is that the image is uploaded into a temporary
pixmap of matching depth (i.e. 32 bit for ARGB32 and 24 bit for RGB23
data), however the core protocol can only blit between Drawables of
matching depth - so without the work-around the Drawables are mismatched
and we either need to use RENDER or fallback.
This patch adds a content mask to _cairo_surface_clone_similar() to
provide the extra bit of information to the backends for when it is
possible for them to drop channels from the clone. This is used by the
xlib backend to only create a 24 bit source when blitting to a Window.
|
|
Avoid calling libtool to link every single test case, by building just one
binary from all the sources.
This binary is then given the task of choosing tests to run (based on user
selection and individual test requirement), forking each test into its own
process and accumulating the results.
|
|
Sigh - finding a crasher in xlib seemed too good to be true. And it was.
The bug is due to the coupling of the XCloseDisplay with the user_data on
the source surface.
This was an externally trigger XCloseDisplay whilst the user had live
surfaces, so I consider this a gross application bug and therefore does
not require graceful handling within cairo-xlib. However, I'm willing to
listen to reason...
|
|
Whilst investigating:
Bug 7360 painting huge surfaces fails
https://bugs.freedesktop.org/show_bug.cgi?id=7360
I found a particular combination of operations that cause a crash within
xlib, so I'm committing the test for posterity.
|
|
77 is the magic exit code used by automake to indicate a skipped test, so
by using it we can get a slightly more informative test log.
|
|
In order to run under memfault, the framework is first extended to handle
running concurrent tests - i.e. multi-threading. (Not that this is a
requirement for memfault, instead it shares a common goal of storing
per-test data). To that end all the global data is moved into a per-test
context and the targets are adjusted to avoid overlap on shared, global
resources (such as output files and frame buffers). In order to preserve
the simplicity of the standard draw routines, the context is not passed
explicitly as a parameter to the routines, but is instead attached to the
cairo_t via the user_data.
For the masochist, to enable the tests to be run across multiple threads
simply set the environment variable CAIRO_TEST_NUM_THREADS to the desired
number.
In the long run, we can hope the need for memfault (runtime testing of
error paths) will be mitigated by static analysis. A promising candidate
for this task would appear to be http://hal.cs.berkeley.edu/cil/.
|
|
Check that the test environment supports the desired source and avoid
triggering asserts in the test routines.
|
|
Inspired by bug 7362 (painting a glitz surface onto an xlib surface
crashes cairo) and the lack of coverage for
_cairo_paginated_surface_acquire_source_image(), these tests attempt
to use each backend as a source surface for all the other backends.
For example, this checks that one can construct a PS file ready for
printing and then copy that surface to an image/xlib for previewing.
|
