[Gnash-dev] u2_has.swf profiling (was: FPS sync)

[strk]

On Wed, May 27, 2009 at 11:39:26PM +0800, Wei Cao wrote:
> hi, all, I tested u2_has.swf on my windows laptop, hope it's not so late . I
> just tried the first 400 frames with the command
> 
>     ./sdl-gnash.exe --max-advances 400 u2_has.swf
> 
> The gnash-0.8.5 with the patch last time I sent uses 61.770s CPU time,
> 51.006s is consumed in draw_shape_character , there are total 84384  calls
> to AGG.
> 
> The optimized version uses 44.744s CPU time, 36.268s in
> draw_shape_character, there are only 32123 calls to AGG now, which means,
> 5/8 calls to AGG and 25% CPU time is saved by cache.

I was finally able to build a profiling version again and 
took a look myself at that movie. It seems to me that in this
case the number of paths in shapes matter a lot. No matter output
size (which usually make a big difference for reduced scanlines
size), u2_has.swf runs very slowly even at a scale of 0.1.

Gprof reports add_path taking a lot of time, and this is used
when gnash::path are converted to AggPaths (path_storage).

I haven't gone deeper (yet) but would be worth inspecting this
piece of code. For example: are AggPath already scaled based 
on the transformation matrix ? If they are not we could have
different kind of shape "modifications" signalled.

We already have the ::set_invalidated call which just calls for
a "need to redraw" event. If I understood your optimizations
they signal a "need to recreate the bitmap cache", which happens whenever
scale or skew changes, but not when offset change.
If paths converted to AGG don't have matrix transform applied we
would have a third event: "need to re-convert paths" which would only
happen for dynamic shapes, as static one *never* change.

Dare going deeper on this ? Or, have a profiling build to give more
info on effect of your patch ?

--strk; 

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!