I've fixed a few issues, packaged up bootanim-2.3-1, and (finally) actually ran some benchmarks. Results (all times in seconds):
fresh os801, from pressing the power button to appearance of sugar's prompt for name screen 80 79 78 with rhgb-client renamed so that init can't find it: 69 68 and with bootanim-2.(1-3) rpm installed: 67 67 67 68 67 If anyone is unconvinced, I could run more tests, but this seems pretty good to me. Its a 15% overall speedup in the boot process. Interesting notes: chkconfig doesn't like binary services - it parses services in /etc/init.d to look for metadata in comments, and the mechanism to override this data (sticking a file with the same name in /etc/chkconfig.d with appropriate comments) doesn't seem to work if the original script can't be parsed. So I had to make small wrappers for ul-warning, boot-anim-start and boot-anim-stop. This doesn't seem to affect performance. I can't seem to get ul-warning to come up properly, so if anyone can tell me what I'm doing wrong that would be great. I've got it to work by manually placing some symlinks in /etc/rc0.d and /etc/rc6.d, but neither Scott's nor my chkconfig comments seem to work. source: http://dev.laptop.org/git?p=users/bobbyp/bootanim koji-built rpms: http://dev.laptop.org/~bobbyp/bootanim/ (koji task https://koji.fedoraproject.org/koji/taskinfo?taskID=1211738 ) I don't know if this could make it into 8.2.1, or what the process would be toward getting it at least in the Rawhide/SOAS images, but it seems pretty low risk (assuming someone can tell me what I'm doing wrong w.r.t. ul-warning). yours, Bobby On Thu, Feb 19, 2009 at 3:03 AM, Mitch Bradley <w...@laptop.org> wrote: > 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