Compiz Core

lp:~smspillaz/compiz-core/compiz-core.fix_880707.2.test

Created by Sam Spilsbury and last modified
Get this branch:
bzr branch lp:~smspillaz/compiz-core/compiz-core.fix_880707.2.test
Only Sam Spilsbury can upload to this branch. If you are Sam Spilsbury please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Sam Spilsbury
Project:
Compiz Core
Status:
Merged

Recent revisions

2914. By Sam Spilsbury

Merge and cleanup the definitions of swapControlSGI

2913. By Sam Spilsbury

Force a redraw time of optimalRedrawTime if we moved from idle to active.

In cases where the plugins are requesting a redraw during donePaint or addWindowDamage,
we should always respect the absolute time difference because on slower systems, or where
double-vsyncs come into effect due to frame limiting, we would force a redraw time of optimalRedrawTime
which meant that plugins could not accurately skip frames, which would mean that the animations
would "appear" to be slower.

However, in cases where we are moving from idle to active, we must always force msSinceLastPaint
to be optimalRedrawTime since with the tickless algorithm, we are measuring the absolute difference
from the last time the screen was drawn to this time, and this difference could be very large.

2911. By Sam Spilsbury

Have a much lower tolerance threshold for phase deviation and allow libdrm
based vblank testing again

2910. By Sam Spilsbury

Added a concept of "work factors" to the tests, eg, some unit of work that
might cause us to miss a vblank and slow us down, adjusted the tests to
make sure that we are always falling under the refresh rate cap, the period
is roughly the same and the phase never deviates past 1

2909. By Sam Spilsbury

Use some more accurate statistics in testing and remove refresh rate detection.

Refresh rate detection is relatively useless when you've got the hardware
already doing vsync for you, and some drivers incorrectly report what the
refresh rate is. Worse, with the ability now to have the refresh rate capped
at a certain framerate *while* vsyncing, if the detected refresh rate actually
falls beneath the vsync period, compiz will wait twice per frame in order
to stay under that value, which hammers performance.

Set a refresh rate cap of -1 to force vsync usage (even if your theoretical
driver allows absurdly small vsync periods). Otherwise the cap will be
applied to the current vsync rate.

2908. By Sam Spilsbury

Expose vblanking in the paint scheduler base and support framerate limiting
with vblanking. Now it is possible to limit the framerate while still keeping
in sync with the monitor (the framerate will decrease roughly in factors of
two, eg 60Hz -> 30Hz -> 15Hz -> 7.5Hz etc)

2907. By Sam Spilsbury

Make the tests fail if the actual framerate exceeds the framerate the user
tried to throttle to

2906. By Sam Spilsbury

Generalized the testcase code into a separate function, allow testing
for throttled refresh rates both with and without vsync

2905. By Sam Spilsbury

Don't create multiple vblank waiter objects

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
Stacked on:
lp:compiz-core/0.9.5
This branch contains Public information 
Everyone can see this information.

Subscribers