Re[4]: [Gnash-dev] invalidated bounds redesign - advice needed

[Udo Giacomozzi]

Hello Martin,

Tuesday, February 13, 2007, 9:21:52 PM, you wrote:
MG> Yes, that should work. The essential thing is to be able to predict an
MG> upper bound on the maximum number of elements so that it cannot
MG> degenerate, however cruel the movie. Once you know how your algorithm
MG> works you will be able to generate a pathological test case or two
MG> that tries to force your code into generating the worst-case scenario
MG> you can imagine.

I implemented the algorithm now (not yet in CVS) and it works well.
Currently it measures the horizontal and vertical distance between
corners and uses the smallest as the criteria. Distances smaller than
10% (configurable) of the scene are merged. This factor seems to be a
good choice for all kinds of movies.

An test movie that contains a large, scaled bitmap (=CPU heavy) and
five moving sprites over it normally played at 4.5 frames per second.
With multiple ranges it now reaches 50 frames per second.

Another movie with 150 randomly placed sprites leads to just one
(sometimes 2 or 3) ranges and of course gives no performance gain -
but it's only about 0.01% to 0.1% slower due to range calculation
overhead.

A real movie (an application) shows noticeably faster response time to
user input, which was the main reason for me to redesign this part of
Gnash.

The algorithm can be modified or redesigned easily without touching
the rest of Gnash. It currently also allows classic single range
calculation for non-AGG renderers.

I still have to clean up much of the code before committing to CVS,
and of course add testcases... ;)

Udo