Cool! Bobby Powers wrote: > 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? >
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 > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel