mirror of
https://github.com/brl/mutter.git
synced 2024-11-26 01:50:42 -05:00
7365c3aa77
This splits out the cogl_path_ api into a separate cogl-path sub-library
like cogl-pango and cogl-gst. This enables developers to build Cogl with
this sub-library disabled if they don't need it which can be useful when
its important to keep the size of an application and its dependencies
down to a minimum. The functions cogl_framebuffer_{fill,stroke}_path
have been renamed to cogl_path_{fill,stroke}.
There were a few places in core cogl and cogl-gst that referenced the
CoglPath api and these have been decoupled by using the CoglPrimitive
api instead. In the case of cogl_framebuffer_push_path_clip() the core
clip stack no longer accepts path clips directly but it's now possible
to get a CoglPrimitive for the fill of a path and so the implementation
of cogl_framebuffer_push_path_clip() now lives in cogl-path and works as
a shim that first gets a CoglPrimitive and uses
cogl_framebuffer_push_primitive_clip instead.
We may want to consider renaming cogl_framebuffer_push_path_clip to
put it in the cogl_path_ namespace.
Reviewed-by: Neil Roberts <neil@linux.intel.com>
(cherry picked from commit 8aadfd829239534fb4ec8255cdea813d698c5a3f)
So as to avoid breaking the 1.x API or even the ABI since we are quite
late in the 1.16 development cycle the patch was modified to build
cogl-path as a noinst_LTLIBRARY before building cogl and link the code
directly into libcogl.so as it was previously. This way we can wait
until the start of the 1.18 cycle before splitting the code into a
separate libcogl-path.so.
This also adds shims for cogl_framebuffer_fill/stroke_path() to avoid
breaking the 1.x API/ABI.
|
||
|---|---|---|
| .. | ||
| conform | ||
| data | ||
| micro-perf | ||
| unit | ||
| config.env.in | ||
| Makefile.am | ||
| README | ||
| run-tests.sh | ||
| test-launcher.sh | ||
Outline of test categories:
The conform/ tests:
-------------------
These tests should be non-interactive unit-tests that verify a single
feature is behaving as documented. See conform/ADDING_NEW_TESTS for more
details.
Although it may seem a bit awkward; all the tests are built into a
single binary because it makes building the tests *much* faster by avoiding
lots of linking.
Each test has a wrapper script generated though so running the individual tests
should be convenient enough. Running the wrapper script will also print out for
convenience how you could run the test under gdb or valgrind like this for
example:
NOTE: For debugging purposes, you can run this single test as follows:
$ libtool --mode=execute \
gdb --eval-command="b test_cogl_depth_test" \
--args ./test-conformance -p /conform/cogl/test_cogl_depth_test
or:
$ env G_SLICE=always-malloc \
libtool --mode=execute \
valgrind ./test-conformance -p /conform/cogl/test_cogl_depth_test
By default the conformance tests are run offscreen. This makes the tests run
much faster and they also don't interfere with other work you may want to do by
constantly stealing focus. CoglOnscreen framebuffers obviously don't get tested
this way so it's important that the tests also get run onscreen every once in a
while, especially if changes are being made to CoglFramebuffer related code.
Onscreen testing can be enabled by setting COGL_TEST_ONSCREEN=1 in your
environment.
The micro-bench/ tests:
-----------------------
These should be focused performance tests, ideally testing a
single metric. Please never forget that these tests are synthetic and if you
are using them then you understand what metric is being tested. They probably
don't reflect any real world application loads and the intention is that you
use these tests once you have already determined the crux of your problem and
need focused feedback that your changes are indeed improving matters. There is
no exit status requirements for these tests, but they should give clear
feedback as to their performance. If the framerate is the feedback metric, then
the test should forcibly enable FPS debugging.
The data/ directory:
--------------------
This contains optional data (like images) that can be referenced by a test.
Misc notes:
-----------
• All tests should ideally include a detailed description in the source
explaining exactly what the test is for, how the test was designed to work,
and possibly a rationale for the approach taken for testing.
• When running tests under Valgrind, you should follow the instructions
available here:
http://live.gnome.org/Valgrind
and also use the suppression file available inside the data/ directory.