| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
The thread id is not used anymore (it is always == 0), so it can be
removed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
A deficiency of cairo-perf-trace is that it currently always uses similar
surfaces for new surface which are kindly cleared by Cairo. This does
not accurately reflect the captured trace and introduces large bandwidth
overheads that distort the profiles.
So we introduce a new boilerplate hook so that the targets can create a
surface without incurring additional overheads.
[Fixes the broken partial commit of bf1b08d066e.]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
| |
|
|
|
|
|
|
|
| |
This function is supposed to describe the backend in use. The describe
function is optional - and therefore initialized as NULL everywhere.
Note:
It is well known that the xlib backend uses X. What is not known is what
version the server supports or what graphics card it is running on. That
is the information the describe vfunc is supposed to provide.
|
| |
|
|
|
| |
Ran a script to align the formal parameters of functions and
collapse spaces to tabs in code.
|
| |
|
|
|
|
| |
In order to exercise the newly restored r5g6g5 support, we need to
create an appropriate surface and feed it through the test and
performance suites.
|
| |
|
|
|
|
|
| |
For the purposes of benchmarking it is useful to run cairo-perf against a
different library from the one it was compiled against. In order to do so,
we need to check that the runtime library contains the required entry
points for our targets - which we can check by using dlsym.
|
| |
|
|
|
|
|
|
|
|
|
| |
By moving the backend target definition out of the massive amlagamated
block in cairo-boilerplate.c and into each of the
cairo-boilerplate-backend.c, we make it much easier to add new targets as
the information need only be entered in a single file and not scattered
across three. However, updating the target interface means trawling across
all the files -- except given that I found it difficult maintaining the
single massive array I do not see this as an increase in the maintenance
burden.
|
| |
|
|
|
|
|
|
|
|
|
| |
Test case for:
Bug 22441 -- Unexpected shift with push_group and pop_group
https://bugs.freedesktop.org/show_bug.cgi?id=22441
This is a test that demonstrates the error in the pdf backend when using
groups on surfaces with non-integer sizes. In order to create such a
surface, we need to update the boilerplate to use doubles instead of
integers when specifying the surface size.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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/.
|
| | |
|
| |
|
|
| |
in preparation for ripping them into per-backend files.
|
| |
|
