Hey,
As some people might know, I've been contacted to make Swfdec run, and
preferrably run fast, as a default UI on an STLinux[1] board. (For
everyone not aware of it, this is an embedded ARM architecture (266MHz
I think?) that uses DirectFB[2] for graphic output.)
This mail is intended as a status report, it contains what I've
learned and done about this in the last week. I've cc'ed Claudio and
the Swfdec list, so interested people can follow my quest and provide
input.
My first quest was to get Swfdec and dependencies cross-compiled. This
has been solved and the whole stack (liboil, glib, pixman, cairo,
pango, swfdec) compiles fine now. Yes, this means, Swfdec even
compiles without warnings with -Werror enabled. Patches have been
pushed upstream, so you get the same experience when using git/svn of
all those packages.
My second quest was to get rid of Gtk when running Swfdec as that
seems like quite a bit of overhead when we just want Flash and not a
whole Gtk application. Besides, it's lots of extra memory and code. So
I created a swfdec-directfb repository which hosts libswfdec-directfb
plus some tools. Expect that repository to change a lot, as it's still
very experimental and I'm still not sure about the APIs of
swfdec-directfb. Input is always welcome though.
The first tool in there is a simple player named
swfdec-directfb-player. It doesn't do mouse/keyboard yet, but I think
I'll get that going soon.
The second tool is swfdec-directfb-bench, which is supposed to become
my benchmark tool of choice for testing the speed of Flash rendering
on DirectFB. It probably requires its own paragraph to explain.
swfdec-directfb-bench is a simple application that prety much works
like a default player. It does in a loop:
a) forward the movie until something on screen changes
b) render the changed parts
And while doing that it measures the time taken. Note that it does not
drop any frames, so it will render the same amount of stuff, no matter
how fast/slow it is. You run it like this: swfdec-directfb-bench
[OPTIONS] file.swf and it outputs how long it took to render all
images of the first 10 seconds (unless changed via --time).
As a total unscientific test, I took Mariorush [3] and tested it with
3 different options both with the old (first result) and Claudio's
rewritten (second result) cairo-directfb backend. Results were as
follows:
300s - 162s - normal playback
300s - 162s - playback with environment variable CAIRO_DIRECTFB_NO_ACCEL set
420s - 172s - playback with -p option, which uses a primary DFB surface
What do I learn from that? Acceleration does not work - at least not
the acceleration provided by the Renesas chip. So there seems to be
some work necessary to make this acceleration available to Swfdec
somehow.
The next steps I'm intending to take are:
1) Having a look at Cairo's performance testsuite and check if SFB is
as slow there, too.
2) Setting up a Swfdec testsuite that does some rendering tests with
various testfiles that will test the various Cairo optimization paths.
Preferrably a testsuite that is not bound to DFB only, but can also be
used by the X11 or other backends.
3) Learn about the chip and figure out how to accelerate it properly
with Cairo. Implement these performance enhancements and write some
guidelines on how to create Flash files hat run fast on that chip.
Cheers,
Benjamin
[1]: http://www.stlinux.com
[2]: http://www.directfb.org
[3]: http://www.onemorelevel.com/games3/mariorush.swf
