On Wed, Feb 11, 2009 at 2:01 AM, Mitch Bradley <w...@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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel