Re[2]: [Gnash-dev] Gnash tutorial on profiling the renderer

[Udo Giacomozzi]

Hello strk,

Saturday, April 25, 2009, 11:53:29 PM, you wrote:
s> For some background, Kristian's case is the case of a company
s> that produces the SWF internally. The profiling goal for them
s> is to improve gnash run of the specific movies. In their case
s> I've observed that bitmap fill rendering was the bottleneck
s> and suggested to use vectors instead. 

Ah, ok. The Wiki page didn't make this clear as it looks like a
general profiling description..


s> As you noticed invalitated bounds doesn't do much good in there
s> as these huge bitmaps shift to the right continuosly. 

s> One characteristic of these bitmaps, which *may* be common to other
s> movies, is that the shape the bitmap fill is applied to doesn't change,
s> and the matrix only changes for the translation part, not scale.
s> If this case is really common, there might be an optimization possible,
s> in particular just dumping a pre-calculated bitmap (save-as-bitmap like
s> thing) to the target rectangle, rather then loop over each scanline
s> and calling the bitmap accessors (which are also virtual calls).

Yes, Flash can set a special option for a movie clip that requests
rendering of the shape to a separate bitmap. So, as long as the shape
itself doesn't change (which is the case for this movie) the bitmap
buffer is just blittet to the stage as needed.

It's called "bitmap caching" and can be set at design and run time.
http://livedocs.macromedia.com/flash/8/main/00001496.html

Gnash could go a step further and do automatic bitmap caching for any
movie clip which could benefit from it as long as not too many
resources are used. The tricky part is finding a good detection and
selection algorithm since bitmap caching means higher memory usage and
might be useless in many cases (even worse: it would slow down
rendering).

Such an *automatic* bitmap caching should be applied only when the
bitmap cache can be blittet to the stage without any visual
degradation, including sub-pixel accuracy. So, just moving a movieclip
at fractions of pixels cannot take advantage of bitmap caching since
the shape is rendered differently in respect to it's position
(anti-aliasing...).

I guess this is not the case for movie clips which are requested to be
bitmap-caches by the designer.


BTW, there is an impressive AGG demo which demonstrates the benefit of
bitmap caches. In the demo (search for "AGG particle demo"), it
multiplicates frame rate by factor 10.

Udo