[Swfdec] swfdec 0.8.2 on MX31 (ARM) very slow

[Benjamin Otte]

On Fri, Dec 12, 2008 at 4:09 PM, Bernhard Kuhn <kuhn at l1nuxh4ck3r.de> wrote:
> In this context: with "normal low" priority, the player does
> 50+ frames per seconds (entering swfmoz_player_redraw). So i'm
> wondering why swfdec never gets into idle for redraw - maybe
> there is something wrong with the timed signaling for redraw on ARM?
> Is it possible to reduce the number of calls to swfmoz_player_redraw?
>
swfmoz_player_redraw() is called after every change to the screen,
which happens after new video or after new flash frames. So 50 frames
per second sounds about right - 25fps for the Flash file, 25fps for
the video.

If you want to slow down the Flash file, you could hack in a call to
swfdec_gtk_player_set_speed() into the plugin. (Or use the --speed
option to swfdec's test player in player/swfplay)

> However, i'm wondering if those empty masking operations are
> a bug in swfdec or if those are truly part of the flash
> script supplied by youtube (maybe as a result of lax programming).
> If it's the later one, then i guess the PCs of millions of youtube
> users are burning more energy than actually necessary for the job.
> Maybe a couple of nuclear power plant could be saved :-)
> (more investigation is needed).
>
There's a lot of "useless" masking going on in Flash files from my
experience, as masking seems to be pretty fast in the Adobe player, so
it's not that much of a performance issue for coders of Flash files.
Usually it's done to avoid layout bugs in the Flash file ;)
But yeah, it requires more investigation into what the Flash file does.

> The flash player itself takes only 10% of the CPU cycles
> for me - that's not too bad, i guess. Maybe it would be a good
> idea to figure out the most over-head causing external functions
> and replace them by some optimized internal version (like the
> i420 to rgb conversion)
>
Question about this: You said that your device uses 16bit colors - so
you could try writing a function that creates an XPixmap (possibly via
XShm and all that magic) in 16bit and not even do an intermediate
32bit conversion and finally use cairo_xlib_surface_create() on that
Pixmap. You have to do this without Cairo, as Cairo doesn't support
16bit. Of course, this requires that Cairo doesn't do fallbacks for
the video rendering.

> In file swfdec_renderer.c the function
> swfdec_renderer_do_create_for_data(),
> doesn't directly return the newly created surface, but
> converts it using swfdec_renderer_create_similar().
> I understand this is necessary for some caching.
>
> However, the creation of the similar surface burns
> a lot of CPU cycles, so i decided to just return
> the pointer to the generated surface, instead:
>
>  // return swfdec_renderer_create_similar (renderer, surface);
>  return surface;
>
Well, the general idea was that it's faster if Swfdec converts image
data to the native format of the display as rendering operations get
way faster when doing that. It worked on my machine ;)
Apparently the performance results for this are different everywhere.

But that is why the SwfdecRenderer API got exported, so you can code
up your own SwfdecRenderer subclass that takes care of making things
fast. (Not that that's a great solution, but you get the idea).

> BTW.: is it possible to disable the caching? I have the impression
> that this is the root cause for the overhead (but that's pure
> speculation at this point in time).
>
You cannot "disable" the caching in that it disables the code paths,
but you can set the cache size to some small value so cached items get
discarded quickly by using g_object_set (player, "cache-size",
(unsigned long) 0, NULL);
(I hope 0 does work, I don't remember the code exactly)

Cheers,
Benjamin