Age | Commit message (Collapse) | Author | Files | Lines |
|
Simply rename a few structures so that their names are less confusing with
the mix of process and threads used to executes traces.
|
|
The meta-surface is a vital tool to record a trace of drawing commands
in-memory. As such it is used throughout cairo.
The value of such a surface is immediately obvious and should be
applicable for many applications. The first such case is by
cairo-test-trace which wants to record the entire graph of drawing commands
that affect a surface in the event of a failure.
|
|
Requires hooking into test-meta-surface currently. Export meta-surface!
The idea is that on detection of an error, we can reconstruct a minimal
trace from the meta-surface. The first step is to simply dump the trace
for the failing meta-surface. Later, we should automatically minimise
this further.
|
|
Oh, it's a bad sign when I can't even correctly compare a bunch of pixels.
|
|
Specify another boilerplate target to use as the reference for this
target. We then use this in cairo-test-trace in preference to using the
image surface. Still not perfect, though the framework is improving.
|
|
Cleanse the code of a couple of redundant pointer manipulations.
|
|
As cairo-test-trace does not clear the image data before reuse, using
the default OVER operator will cause differing results for each process
when inadvertently alpha blending into the shared memory region. As we
essentially want to just copy the source pixels, be explicit and set the
SOURCE operator.
|
|
cairo-test-trace's shared memory allocation pattern is much simpler than
anticipated as it allocates a bunch of images and then frees them all,
and so only needs a simple linear allocator.
|
|
Review cairo-test-trace.c and rewrite parts to ease understanding and fix
various bugs - such as failure to notice the slaves crashing and not
releasing our shared memory after an interrupt.
|
|
The basic premise is that we feed the trace to multiple backends in
parallel and compare the output at the end of each context (based on
the premise that contexts demarcate expose events, or their logical
equivalents) with that of the image[1] backend. Each backend is
executed in a separate process, for robustness, with the image data
residing in shared memory and synchronising over a socket.
[1] Should be reference implementation, currently the image backend is
considered to be the reference for all other backends.
|