[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] youtube profiling
From: |
strk |
Subject: |
Re: [Gnash-dev] youtube profiling |
Date: |
Thu, 3 May 2007 11:25:19 +0200 |
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;
- [Gnash-dev] youtube profiling, strk, 2007/05/03
- Re: [Gnash-dev] youtube profiling, Udo Giacomozzi, 2007/05/03
- Re: [Gnash-dev] youtube profiling,
strk <=
- Re[2]: [Gnash-dev] youtube profiling, Udo Giacomozzi, 2007/05/03
- Re: [Gnash-dev] youtube profiling, strk, 2007/05/03
- Re[2]: [Gnash-dev] youtube profiling, Udo Giacomozzi, 2007/05/03
- Re: [Gnash-dev] youtube profiling, strk, 2007/05/03
- Re[2]: [Gnash-dev] youtube profiling, Udo Giacomozzi, 2007/05/03
- Re: [Gnash-dev] youtube profiling, strk, 2007/05/04