Initial OFW screen needs to match design.

[JordanCrouse]

As per #519, we need an image for the splash screen during boot. On the advice of jg, I'm opening a new bug and assigning it to Walter.

[Eben]

I've laid out startup and shutdown sequences in ticket #692, which cleanly integrate with the visual design in the rest of the interface and avoid the slideshow-like sequences most computers have, for simplicity. If that spec is closely adhered to, we basically want a static screen - light gray with a white outlined XO - to appear as soon as possible, which can then be replaced with a rendered SVG version, transparently to the user, once the boot process has gotten far enough.

[Eben]

I've attached a startup screen image to this ticket. This should appear as soon as possible (ideally, the screen should transition from black directly to this). This should remain until boot has reached a point at which we can replace it with a dynamically rendered SVG. The transition between static and dynamic is of utmost importance: there should be absolutely no visible gap at the moment of transition in order to make startup feel seamless. Likewise, if there is another transition to the true Home screen when the ring becomes visible, this too should be seamless.

In order to make the transitions as seamless as possible, here are the details of the static screen to match on the dynamic startup screen (and also the Home screen).

XO size: stock-buddy SVG scaled by 275%
XO position: dead center, its center point at (600, 450)
XO stroke: #FFFFFF
XO fill: none (until dynamic screen animation begins)
Background color: #E2E2E2

[Eben]

XO stroke weight: 6 pt.

[marco]

Design part is done. Assigning to OFW since I guess that's where it will have to be implemented.

[Eben]

The recent designs have a slightly darker background color: #C0C0C0. This should be noted and adjusted in all parts of the boot sequence so that the color of the background remains seamless throughout.

[kimquirk]

moving to Trial-3, raising priority. I know Walter discussed an animation for boot time.

[marco]

This should be assigned to someone which has a clue about OFW. I think bernie mentioned he had code to unfreeze the DCON in sugar. Reassigning to jg to figure out who should take this one.

[cscott]

In bug #2667 I've attached a patch which freezes the DCON to enable 'pretty boot' if the left directional arrow is held during boot. Mitch is probably the logical person to move something like this into OFW and replace the white screen with the XO man, although I might work on a patch while I'm in California if I run out of other tasks I can do w/o ready access to a schoolserver.

I can also write/launch a little process which starts to pulse the XO man once we've reached the initrd, although I might need help transitioning to an XO man in the X background when it starts up. Is there a specification for how the 'pulsing' works, somewhere? Really helpful would be a 5-10 PNG image sequence I can flip through to animate the pulsing, since that's how my framebuffer write code would work (until X had launched and we could do real SVG rendering, etc).

Reassigning to Eben for info on the pulsing animation; reassign to me afterwards.

[Eben]

Well, the specification for the pulsing is a sinusoidal fade between (white, transparent) and (stroke, fill) colors for the XO with a frequency of about 1/2 Hz, or maybe a little slower. I'd like to manage roughly 10fps here, if possible, but slower would be acceptible; let's do what we can.

Of course, the essential aspect of the pulsing is that it pulses in the color of the XO, and as such if we want to accomplish this before we reach X, we need to dynamically generate a sequence of 20 frames using the XO colors each time the colors are changed (right now, only after first boot...). What's the likelihood of being able to a) generate these images dynamically and b) stuff them into the initrd so they're accessible.

Assuming we can accomplish this, we should initialize these 20 frames with a cropped startup_screen.png so that it simply remains static on first boot when there are no colors specified. Also, if we do this, we need to somehow make the transition to an X-rendered SVG match the phase of the initrd step. That sounds a little tricky....it might be simpler to do one or the other. Can someone give me a rough breakdown of the timeline during boot and what we can do at each step?

[cscott]

10fps shouldn't be a problem, I don't think, if the images are prerendered and stored in native framebuffer format (16-bit 565). The images don't need to be stuffed into the initrd, they can live in the main filesystem if we're willing to wait a fraction of a second more for it to mount before we start pulsing.

My impression of boot is that the time from X startup to sugar start is fairly short, compared to the delay between OFW and X. Matching the phase would indeed be tricky. Can we mask this transition in some other way? For example, fade all the way down to outline, DCON freeze and hold there for a moment while X starts, and then either fade or pop to the colored XO?

Rough breakdown of boot steps:

a) open firmware starts b) open firmware probes USB, SD, NAND looking for boot device c) open firmware authenticates and decompresses linux kernel and ramdisk

above this line, we can do a static XO image. Mitch might be able to do limited

animation, perhaps by using a timer interrupt, but he wouldn't have access to the customized XO colors and it would be hard to stuff them somewhere OFW could quickly get to

d) linux begins boot and does initial initialization

really, we can only maintain a static image here

e) linux userland gains control (initial ramdisk) f) root filesystem is mounted

by this point we can do animation. we can't use custom colors until the root filesystem is mounted, as the initial ramdisk is cryptographically signed & thus can't be altered by the user (w/o developer key, etc, etc)

g) /sbin/init runs -- this is the 'Initializing Fedora' and all the [OK]s. Lots of services are started -- but we can continue animating through this. h) X is started. Static background. Transfer of control from the early userland animator to X. i) Full dynamic SVG rendering can occur, within X. j) Sugar starts, and slowly draws each left, top, bottom, (pause) right borders. I personally think this looks ugly, and would rather see the frame pop into existence.

My suggestion would be to start the animation as soon as the root filesystem is mounted, and fade to white outline just before X is started (X may wait for animation to reach the desired point). We then freeze the DCON, start X, and unfreeze once the sugar interface is completely up, so that it appears all at once.

The animation rendering would happen right after user colors were chosen, and the animated sequence would live in /home/olpc somewhere.

jg - if we were to do a seamless animation transition across X startup, could we get an X application up in the root window within 100 ms (or thereabouts) of invoking X? If so, then we can consider handing off the animation, instead of freezing the display momentarily at the end of the startup sequence.

[cscott]

Retitling and repurposing this bug. We have a startup design in trac #1543 and on the wiki at http://wiki.laptop.org/go/Startup_Sequence.

The first OFW screen should be grey, not white, and have the 'XO guy' centered.

Presumably the boot-status icons should still be visible somewhere (in the top corner, as at present?).

[wmb@…]

Fixed in q2c28, when in secure mode.