mutter

brl/mutter

History

Emmanuele Bassi 83b4ec7a12 units: Cache the pixels value inside Units When computing the pixels value of a ClutterUnits value we should be caching the value to avoid recomputing for every call of clutter_units_to_pixels(). We already have a flag telling us to return the cached value, but we miss the mechanism to evict the cache whenever the Backend settings affecting the conversion, that is default font and resolution, change. In order to implement the eviction we can use a "serial"; the Backend will have an internal serial field which we retrieve and put inside the ClutterUnits structure (we split one of the two 64 bit padding fields into two 32 bit fields to maintain ABI); every time we call clutter_units_to_pixels() we compare the units serial with that of the Backend; if they match and pixels_set is set to TRUE then we just return the stored pixels value. If the serials do not match then we unset the pixels_set flag and recompute the pixels value. We can verify this by adding a simple test unit checking that by changing the resolution of ClutterBackend we get different pixel values for 1 em. http://bugzilla.openedhand.com/show_bug.cgi?id=1843		2009-10-16 15:25:37 +01:00
..
conform	units: Cache the pixels value inside Units	2009-10-16 15:25:37 +01:00
data	[build] Split out the custom silent rules	2009-09-16 17:47:59 +01:00
interactive	[text] Add pre-edit string to ClutterText	2009-10-16 12:45:29 +01:00
micro-bench	[build] Split out the custom silent rules	2009-09-16 17:47:59 +01:00
tools	[build] Split out the custom silent rules	2009-09-16 17:47:59 +01:00
.gitignore	[gitignore] Ignore new test-color-hls-roundtrip test	2009-08-03 14:25:08 +01:00
Makefile.am
README	[docs] Fix typos and remove mentions of SVN	2009-07-12 01:38:40 +01: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 approach taken for testing.