Opportunity for speedup

[Mitch Bradley]

Cool!

Bobby Powers wrote:
> 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?
>   

Yes on both counts.  Stopwatch on freshly-flashed os7.img .


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

To reduce the execution footprint, you could try linking it against 
dietlibc, http://www.fefe.de/dietlibc/

I'm not sure just how much time that would save; maybe it wouldn't be 
significant.  But it's worth a try.


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