[Swfdec] Problems on porting swfdec on NXP

[Benjamin Otte]

I'm gonna CC the swfdec mailing list, as I think it's interesting for
everybody thinking about Swfdec on embedded.

> I have cross-compiled swfdec0.7 on directfb, and the  swfdec-directfb-player
> can work on NXP platform ,
>
> The CPU cost is high, video can be viewed continuesly , however no audio
> output.
>
The DirectFB player was the result of a project we did to find out
what work would be required to make Swfdec run on embedded devices and
how long that would take. As such, it is an unfinishd product, which
is why I never released it. Missing audio support is probably the
biggest missing feature. It simply was not required in our project.
For your information, here's the important things we learned in this project:
- Memory use is very dependant on the Flash file. Average files
however are handled fine. The number I remember was that running
Youtube took around 10MB of memory.
- Performance depends a lot on the Flash file in use. If Swfdec has to
use software fallbacks when something is not accelerated, your speed
drops to roughly 1/100th of what it achieves with accelerated
graphics. So if you intend to only run specific Flash files on your
device, it makes a lot of sense to spend time tuning them.
- Performance of the graphic subsystem is very important. DirectFB
drivers should at least accelerate blits for useful output. But ever
feature helps.
- The Cairo DirectFB backend is very bad at making use of the
accelerated features of the graphics card. It would need to be
seriously overhauled to make Swfdec really fly on Embedded.

Or in short: If your Flash file does software rendering, you lose.

> 2. I have also cross-compiled swfdec0.6 on gtk,  the gtk-demo(gtk
> demo app) run correctly , but the swfplay (swfdec on gtk demo app) crashes
> with abort  or  segment fault  and with no other message when  starting play
> swf files.  I can trace  gtk api (Update UI)  where crashes. I have no idea
> to resolve it ,could you give some advice.
>
The swfdec-gtk code is tuned for desktop machines and uses cache sizes
appropriate for current desktops (I believe 50MB). This is too large
for lots of embedded devices and can cause out-of-memory failures
pretty easily. We added options for cache sizes to the directfb player
to get around this.

> 3. Runtime bugs resolving,how to fix them for me? Flash and swfdec,
> who is imcompatible with who?
>
If something runs in Adobe's Flash player, but not in ours, it's
always a bug in Swfdec. If it doesn't run in Adobe's player, it's a
bug in the Flash file. And if it works in Swfdec, that's a bug in
Swfdec, too.

> swfdec-directfb-player /opt/gtkdfb-mipsel/bin/dh28011.swf
>
> (swfdec-directfb-player:617): Swfdec-WARNING **: Could not convert string
> from LATIN1 to UTF-8
>
> (swfdec-directfb-player:617): Swfdec-CRITICAL **:
> swfdec_as_context_give_string: assertion `string != NULL' failed
>
If this Flash file is not secret, could you provide us with it? Those
are error messages that should never happen and I need to fix them.

> 4. Could you provide a demo app for swfdec action script debugger?
>
All debugging tools in Swfdec are written to allow us to bugs in
Swfdec, so I'm not sure they are very useful in tehir current state
for anyone not working on Swfdec internals.
However, we'd be very happy if someone wanted to work on them to make
them more useful in general. :)

Cheers,
Benjamin