Opportunity for speedup

[Bobby Powers]

On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley <wmb at laptop.org> wrote:
> I just measured the time taken by the boot animation by the simple
> technique of renaming /usr/bin/rhgb-client so the initscripts can't find it.

how did you measure exactly? stopwatch? I'd like to recreate the
tests.  It sounds like you did this on a freshly flashed system?

> With boot animation, OS build 7 (an older 8.2.1 candidate) takes 60
> seconds from first dot (indicating OFW transfer to Linux) to Sugar
> "prompt for your name".   Without it, 53 seconds.  I repeated the test
> several times with consistent results.
>
> Clearly, it should be possible to display that amount of information in
> much less than 7 seconds.
>
> The boot animation code is in the OLPC domain, not the upstream domain,
> so replacing it should be relatively free of upstream politics.
>
> So if anybody is interested in implementing a relatively simple
> boot-time speedup, I offer this as low-hanging fruit.
>
> I suggest 1 second (differential time between animation and no-animation
> cases) as a reasonable target goal, assuming images of the complexity of
> the current ones.  Arbitrary full-screen graphics might require more
> time, but speeding up the baseline case is a good starting point.
>
> Go wild.

So I've taken a first cut at this, implemented with the following
design considerations (mostly from a conversation with Mitch)
- the Python client/server was reimplemented as several standalone C
programs (boot-anim-start, boot-anim-client, and some cleanup in
boot-anim-stop)
- a client and server was used before because there is state
information that needs to be saved: we need to keep track of where in
the animation we are.  We can keep track of this by using offscreen
memory in the framebuffer (its 16MB in size, and only the first 2ish
MB is used for the onscreen graphics (my terminology might be off
here)).  For state we really only need to keep track of 2 integers,
one for the current frame number and another to store the offset of
the next diff to apply.
- on startup we load an initial image into the framebuffer (the first
1200*900*2 bytes, since we use 2 bytes per pixel for color
information), and then load in a series of changes to the framebuffer
image (<300KB).  This takes the form of a series of diffs
- for each update (a valid call to boot-anim-client) we apply the next
diff in the series to the onscreen image and update our state
information
- after applying the last diff we have (the end in the animation
series), freeze the DCON (when I first attempted to freeze the DCON
when z-boot-anim-stop was called it left the screen in an inconsistent
state, I believe because of X startup)
- its designed to be as light as possible, using syscalls instead of
libc functions as much as possible (the only thing we use libc for is
string comparison, which could be replaced with a local function).
while its written like this, I haven't worked on cutting down the
linking (I need some guidance for that)

comments and suggestions welcome :)

I'd appreciate any testing as well as any code review.  (the shutdown
image appears to be broken, FYI.  i haven't looked at that in depth,
its probably a one line fix.)
rpms (built with mock) are available at
http://dev.laptop.org/~bobbyp/bootanim/
and source is avail at
http://dev.laptop.org/git?p=users/bobbyp/bootanim

-Bobby