mutter/tests
Neil Roberts 89e7552ca3 Bug 1172 - Disjoint paths and clip to path
* clutter/cogl/cogl-path.h:
	* clutter/cogl/common/cogl-primitives.c:
	* clutter/cogl/common/cogl-primitives.h:
	* clutter/cogl/gl/cogl-primitives.c:
	* clutter/cogl/gles/cogl-primitives.c: Changed the semantics of
	cogl_path_move_to. Previously this always started a new path but
	now it instead starts a new disjoint sub path. The path isn't
	cleared until you call either cogl_path_stroke, cogl_path_fill or
	cogl_path_new. There are also cogl_path_stroke_preserve and
	cogl_path_fill_preserve functions.

	* clutter/cogl/gl/cogl-context.c:
	* clutter/cogl/gl/cogl-context.h:
	* clutter/cogl/gles/cogl-context.c:
	* clutter/cogl/gles/cogl-context.h: Convert the path nodes array
	to a GArray.

	* clutter/cogl/gl/cogl-texture.c:
	* clutter/cogl/gles/cogl-texture.c: Call cogl_clip_ensure

	* clutter/cogl/common/cogl-clip-stack.c:
	* clutter/cogl/common/cogl-clip-stack.h: Simplified the clip
	stack code quite a bit to make it more maintainable.  Previously
	whenever you added a new clip it would go through a separate route
	to immediately intersect with the current clip and when you
	removed it again it would immediately rebuild the entire clip. Now
	when you add or remove a clip it doesn't do anything immediately
	but just sets a dirty flag instead.

	* clutter/cogl/gl/cogl.c:
	* clutter/cogl/gles/cogl.c: Taken away the code to intersect
	stencil clips when there is exactly one stencil bit. It won't work
	with path clips and I don't know of any platform that doesn't have
	eight or zero stencil bits. It needs at least three bits to
	intersect a path with an existing clip. cogl_features_init now
	just decides you don't have a stencil buffer at all if you have
	less than three bits.

	* clutter/cogl/cogl.h.in: New functions and documentation.

	* tests/interactive/test-clip.c: Replaced with a different test
	that lets you add and remove clips. The three different mouse
	buttons add clips in different shapes. This makes it easier to
	test multiple levels of clipping.

	* tests/interactive/test-cogl-primitives.c: Use
	cogl_path_stroke_preserve when using the same path again.

	* doc/reference/cogl/cogl-sections.txt: Document the new
	functions.
2008-12-04 13:45:09 +00:00
..
conform * tests/conform/test-backface-culling.c (TEXTURE_SIZE): Don't set 2008-11-28 17:45:54 +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 Bug 1172 - Disjoint paths and clip to path 2008-12-04 13:45:09 +00:00
micro-bench Bug 1162 - Re-works the tests/ to use the glib-2.16 unit testing 2008-11-07 19:32:28 +00:00
tools Add a wrapper library to help testing without NPOTs. 2008-11-24 15:44:16 +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

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.