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

[Bernhard Kuhn]

Hi Benjamin!

Thanks for your helpful reply and sorry for my delayed response.
In the mean time, i got more findings (please read inline, below).


Benjamin Otte wrote:

> The short version is that user input > redraws from user input >
> advancing the flash file > redraws from advancing. Unfortunately, if
> advancing takes longer than real time, no redraws ever happen.

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?


> Interesting - I wasn't aware that any masking is going on in the
> Youtube player. This is likely gonna cause you problems on non-Youtube
> files as you disabled masks, but I guess you know that.

Right, in fact, for some videos, you may temporarily see some
tearing when masking is disabled. A funny thing is that the masks
are all zeros, most of the time, so the appropriate masking
operation has *no* effect at all! During my first experiments,
i added a simple function in libpixman that checks if a mask
is non-zero before applying the operation (and skipping the
operation, otherwise) - this got me a few FPS, but because the
masking is mostly useless, i disabled it altogether for now.
The idea is to have hw-accelerated functions, later on so that
even the bogus masking operations could be applied without
performance loss.

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).


> You could also try removing all the debugging stuff by exporting
> CFLAGS="-DG_DISABLE_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CAST_CHECKS
> -DSWFDEC_DISABLE_DEBUG"

Thanks for the hint - that got me a couple of FPS, but there is
still plenty of time spent in libglib and libgobject because
of run-time time-checking. I guess i would need to re-compile
other libraries with those options to reduce the overhead.


> But yeah, the script engine is known to be slow as we never optimized
> our code for speed, but correctness and easy debugging and refactoring
> whenever we figured out it's not correct. So we're missing all the
> cool optimizations from Mozilla or Webkit.

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)


Another finding:

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;

Another side effect of this is that pixman then somehow
magically doesn't need to do the rgb888-to-rgb555 color conversion
and the rgb555-to-rgb555 strech blit in two steps. Instead,
a combined rgb888-to-rgb555 strech blit color conversion is
done (that addressed with a hand-optimized version).

So these two things also got me a couple of FPS.



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).

regards

Bernhard