Re: [Gnash-dev] youtube profiling

[strk]

On Thu, May 03, 2007 at 11:09:29AM +0200, Udo Giacomozzi wrote:
> Hello strk,
> 
> Thursday, May 3, 2007, 10:54:50 AM, you wrote:
> s> I've done some profiling playing youtube.
> s> The bottleneck is still the rendering. In particular, video frame 
> rendering.
> 
> With AGG? I'm using nearest neighbor scaling, which should be the
> fastest method that can do scaling. Of course just copying the data to
> the offscreen buffer when the video is scaled 1:1 would be faster, but
> I'm a bit scared of implementing that.

Yes, with AGG. Here's more data:

[1]     90.0    0.00   20.50                 
gnash::Gui::advance_movie(gnash::Gui*) [1]
                0.00   19.16     464/464         
gnash::Gui::display(gnash::movie_root*) [2]
                0.00    1.34     464/464         
gnash::movie_root::advance(float) [29]

90% of total run time originates (of course) in ::advance_movie.
core lib advancement (movie_root::advance) accounts for 1.34 seconds, while 
Gui::display
accounts for 19.16 seconds (over 20.50 total).

[6]     55.5    0.00   12.64     388         
gnash::video_stream_instance::display() [6]
                0.00   12.60     375/375         
gnash::render::drawVideoFrame(image::image_base*, gnash::matrix const*, 
gnash::rect const*) [8]

Of those 19.16 seconds above, the most time is spent in 
video_stream_instance::display, which in 
called 388 times calling drawVideoFrame() 375 times (accounting for 12.6 
seconds).

[8]     55.3    0.00   12.60     375         
gnash::render::drawVideoFrame(image::image_base*, gnash::matrix const*, 
gnash::rect const*) [8]
                0.00   12.60     375/375         
gnash::render_handler_agg<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8,
 agg::order_rgb>, agg::r
ow_accessor<unsigned char> > >::drawVideoFrame(image::image_base*, 
gnash::matrix const*, gnash::rect const*) [7]

This takes us to AGG, and in particular to: 

[7]     55.3    0.00   12.60     375         
gnash::render_handler_agg<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8,
 agg::order_rgb>, agg::row_a
ccessor<unsigned char> > >::drawVideoFrame(image::image_base*, gnash::matrix 
const*, gnash::rect const*) [7]
                0.00   12.60     375/375         void 
agg::render_scanlines_aa<agg::rasterizer_scanline_aa<agg::rasterizer_sl_clip<agg::ras_conv_int>
 >, agg::s
canline_u8, 
agg::renderer_base<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8, 
agg::order_rgb>, agg::row_accessor<unsigned char> > >, agg::span_al
locator<agg::rgba8>, 
agg::span_image_filter_rgb_nn<agg::image_accessor_clip<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8,
 agg::order_rgb>, agg::
row_accessor<unsigned char> > >, 
agg::span_interpolator_linear<agg::trans_affine, 8u> > 
>(agg::rasterizer_scanline_aa<agg::rasterizer_sl_clip<agg::ras_conv_int
> >&, agg::scanline_u8&, 
> >agg::renderer_base<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8,
> > agg::order_rgb>, agg::row_accessor<unsigned char> > >&
, agg::span_allocator<agg::rgba8>&, 
agg::span_image_filter_rgb_nn<agg::image_accessor_clip<agg::pixfmt_alpha_blend_rgb<agg::blender_rgb_pre<agg::rgba8,
 agg::or
der_rgb>, agg::row_accessor<unsigned char> > >, 
agg::span_interpolator_linear<agg::trans_affine, 8u> >&) [9]

> s> Profile output shows that the drawVideoFrame routine is called 375.
> 
> 375 times? More interesting would be the real time which is spend in
> that routine.

... render_scanlines_aa ... (375 times, for a total of 12.6 seconds).

> s> This is the RMS singing video, which is 02 minutes and 01 second long.
> s> The player2.swf file is at 25 FPS, which means 3025 calls to ::advance
> s> during the playback. I assume most of the times a new frame
> s> is not ready so we don't display anything...
> 
> Are you sure it really won't update in that case? This requires
> correct usage of invalidated bounds (set_invalidated()) and as far as
> I remember only minimal functionality for invalidated bounds were
> implemented in the video class. This could have changed in the
> meantime..

I just see that render_scanlines_aa (or drawVideoFrame) is only called
375 times, over 464 total calls to ::advance (now noticing).

So one thing to note is that altought requested execution would want
3025 calls to ::advance (25FPS *~ 02:01 seconds) we only call ::advance
about 400 times, probably due to the fact we'r too slow.

Now my question was about the number of actual frames in the FLV becase
if that number is much smaller then our '375' we are likely updating
more then we should. I'm sure invalidated bounds are not implemented in
video_frame_instance. Another question would be: would implementing properly
invalidated bounds still alwayus call drawVideoFrame ?

--strk;