mutter

brl/mutter

History

Robert Bragg e338245827 Renames the mesh api to the "vertex buffer api". This better reflects the fact that the api manages sets of vertex attributes, and the attributes really have no implied form. It is only when you use the attributes to draw that they become mesh like; when you specify how they should be interpreted, e.g. as triangle lists or fans etc. This rename frees up the term "mesh", which can later be applied to a concept slightly more fitting. E.g. at some point it would be nice to have a higher level abstraction that sits on top of cogl vertex buffers that adds the concept of faces. (Somthing like Blender's mesh objects.) There have also been some discussions over particle engines, and these can be defined in terms of emitter faces; so some other kind of mesh abstraction might be usefull here.		2009-01-20 22:29:35 +00:00
..
conform	Renames the mesh api to the "vertex buffer api".	2009-01-20 22:29:35 +00:00
data	Bug 1162 - Re-works the tests/ to use the glib-2.16 unit testing	2008-11-07 19:32:28 +00:00
interactive	Merge branch 'cogl-float'	2009-01-20 18:47:50 +00:00
micro-bench	[test-text] queue redraws instead of calling clutter_actor_paint directly	2009-01-15 14:25:22 +00:00
tools	Make libdisable-npots a bit more portable	2009-01-05 17:11:44 +00:00
Makefile.am	2008-11-17 Emmanuele Bassi <ebassi@linux.intel.com>	2008-11-18 09:50:03 +00:00
README	Bug 1162 - Re-works the tests/ to use the glib-2.16 unit testing	2008-11-07 19:32:28 +00:00

README

Outline of test categories:

The conform/ tests should be non-interactive unit-tests that verify a single feature is behaving as documented. See conform/ADDING_NEW_TESTS for more details.

The micro-bench/ tests should be focused perfomance test, ideally testing a single metric. Please never forget that these tests are synthetec 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 interactive/ tests are any tests whos status can not be determined without a user looking at some visual output, or providing some manual input etc. This covers most of the original Clutter tests. Ideally some of these tests will be migrated into the conformance/ directory so they can be used in automated nightly tests.

Other 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 aproach taken for testing.