Closed Bug 799714 Opened 12 years ago Closed 12 years ago

Define startup graphics and/or animation

Categories

(Firefox OS Graveyard :: Gaia, defect, P1)

All
Other
defect

Tracking

(blocking-basecamp:+)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp +

People

(Reporter: pla, Assigned: mwu)

References

Details

(Whiteboard: visual design UX-P1, QARegressExclude)

Attachments

(2 files)

From Github Issue #2556.

--

jcarpenter opened this issue 3 months ago
Define startup graphics and/or animation

No milestone
PeterLa is assigned
Need to define the startup visual sequence:

    Logo / partner logo?
    Progress bar / activity indicator?
    Looping animation?
    Sound

As per late-June email thread "B2G start up animation/sound - due diligence":

    On Jun 27, 2012, at 9:25 PM, Chris Jones wrote:

    There are two things here, in sequence ---

        1. bootloader image/animation, while the kernel starts up
        2. userspace loading animation, while Gecko starts up

    We should definitely show a branded screen for (1), but it's actually quite difficult and risky technically to do right now. (Need to build and flash our own bootloader.) This is easy in a production build. Showing an animation here is very hard.

    I think (2) is mostly being discussed below. This animation basically says to users, "My startup time is too slow, enjoy this distraction while I flounder around" :). We should strive for a fast enough startup time to make this uninteresting; 10s or a little less is feasible on low-end devices. But it is quite easy technically to play any kind of static animation we want during userspace startup.

Current consensus is:

    Logo
    Maybe a progress bar / activity indicator
    Maybe a sound

... and we leave out the looping animation.

6 participants
etiennesegonzac referenced this issue 3 months ago
Closed
Issue #1638: [Otoro] Remove the Android Icon on device startup
etiennesegonzac commented 3 months ago

Please try to avoid duplicates, it's going to become un-manageable really fast.
jcarpenter commented 3 months ago

Blocked by branding. Need clarity there. Will probably address this last.
autonome commented a month ago

@patrykdesign @jcarpenter any update?
jcarpenter commented a month ago

@cgjones We you mind clarifying once more the device loading sequence, and our options for each step?

    Bootloader - Still image only, or can we also do image sequence? Duration?
    Userspace (Gecko loading) - Image sequence? Duration?
    Gaia loaded - Have total freedom?

My understanding from our Sao Paulo chat was steps 1 + 2 = approximately 30 seconds?

Based on chats in Sao Paulo, we told branding there would be:

        Boot screen loop: Animation loop (recommend 10-20) secs representing FxOS. Similar to Android's loading animations. Could alternatively be a still image, ala iOS's Apple logo, but 30-60 sec is too long not to indicate some sort of activity to the user.

        Logo animation: Separate animation from Boot, starts immediately after Boot, introduces OEM, FxOS, and Carrier logos in succession. Possibly only shown on FTE.

Once we confirm I can provide placeholder animations. Would @michaelwu be involved with loading the bootloader animation assets?
jcarpenter commented a month ago

I have created a placeholder PNG sequence here: https://www.dropbox.com/sh/bim117t5niqry73/9W_AF_mdOL

That's 10 seconds, and should loop seamlessly.

I'd like to get that loaded onto Otoro asap to test.

One thing I realized: that sequence is 18 mb. That's drastic bloat to our FOTA updates. We could:

    Use more compression (JPEGs?) to reduce file size (I believe @cgjones indicated this has performance consequences...)
    Reduce the duration of the loop
    Reduce the size of the images (occupy small part of screen instead of full thing)
    Drop entirely and use stills, and perhaps dash of CSS animation (CSS out of question for bootloader though)

@cgjones @michaelwu, please advise. Thanks!
vingtetun commented a month ago

As far as I understand the scope of this feature, no CSS is doable in step 1 and step 2.
jcarpenter commented 22 days ago

@patrykdesign I estimated LOE:M for this task. Feel free to change.
michaelwu commented 19 days ago

I can only help with things in #2 - userspace.

The dropbox link doesn't seem to download for me.

The bootloader is almost always just a single image, but android phones often have an animation after the bootloader splash since android startup is usually pretty slow.
jcarpenter commented 19 days ago

    The dropbox link doesn't seem to download for me.

Yeah I see that also. It looks the user needs to click on the file, and then select "Download" from the subsequent page. It's not as straightforward as alt-clicking on the link. DB lesson learned :)

    The bootloader is almost always just a single image, but android phones often have an animation after the bootloader splash since android startup is usually pretty slow.

Yes, that rings true. My Nexus boots to "Google" still image for approx 6 seconds,then goes into a looping animation for 12 or so.

Does the current "mozilla" logo live on the bootloader or user space?
michaelwu commented 19 days ago

The current mozilla logo is in two places. It's first loaded by the first userspace program that starts, and then shown again by gaia with a mismatched background.

One interesting thing to note about these splash images - they often use the simplest and quickest image compression possible - RLE. Once the phone gets to userspace, it's no problem to use png or jpeg though it may slow booting.
cgjones commented 17 days ago

This is summarizing a recent IRC chat. The startup sequence looks something like

    power on phone: screen is off
    bootloader(s) start up: one of them turns on the screen. the mozilla logo needs to be in the framebuffer then. this is 100% the vendor's responsibility. (There's currently a bug here.)
    bootloader starts linux, linux starts android service manager. the logo drawn by the bootloader should still be in the framebuffer

--- Question: does the linux driver blank out the framebuffer when it loads? ---

    at this point, we can spawn a userspace process to draw animations etc. this is what android does

--- If the bootloader-drawn logo is still in the framebuffer, we don't need to do this. If it gets blanked out, we need to measure how long it takes for gecko to take over the framebuffer. If that's short, we may not have to do anything here. If it's long, we probably do. Have to measure. ---

    gecko will start up and eventually take over the framebuffer

--- I'm pretty sure, but not 100% sure, that when gecko does this it blanks the fb. We need to check this. ---

    currently it draws black until gaia finishes starting up. it could instead draw an image or animation, but this is new code required
    gaia system app starts up

@michaelwu can you help us figure out the answers to the question above?
cgjones commented 17 days ago

Following up on the question from @jcarpenter on IRC: gecko drawing a static image to the framebuffer before gaia is up is LOE:S. Animation is LOE:?; depends on the animation.
jcarpenter commented 17 days ago

@cgjones Once Gaia is fully loaded, can you suggest which image sequence animation approach will be most performant, based on options listed here: http://awardwinningfjords.com/2012/03/08/image-sequences.html ? Am asking in context of First Time Experience, where we'd like to incorporate a quick animation either at start or completion.
cgjones commented 15 days ago

Most likely an (async) CSS animation.
autonome commented 6 days ago

Blocking-. We have to focus on stabilization and fixing of functional bugs, see https://wiki.mozilla.org/B2G/V1StabilizationPhase.

Once the functional issues are fixed, if a patch becomes available for this issue and it has tests and passes the smoketest, file it at https://bugzilla.mozilla.org/enter_bug.cgi?product=Boot2Gecko&component=Gaia and ask for driver approval.
jcarpenter commented 6 days ago

@PeterLa is going to be driving this for UX, going forward.
Severity: normal → blocker
Keywords: polish
Priority: -- → P1
Depends on: 809665
Michael, Dietrich,

What's the status of this currently?  I haven't seen this in any of the nightlies yet.  What do we need to do to get this in?
blocking-basecamp: --- → ?
should need Chris Lee input, this is more on marketing and customization request
Flags: needinfo?(clee)
Peter, can you summarize the current state of what's been implemented against the agreed upon UX?  

From a branding/product perspective, we'll want a well defined set of startup graphics.  Blocking for now, but will be necessary to evaluate how far we are off from the intended design.
blocking-basecamp: ? → +
Flags: needinfo?(clee)
From what Michael Wu has shown me, the implementation he has is exactly what's been spec'd.  We did talk about revising the animation with brand, but that's currently stalled, and if it doesn't move, we will just stick with the current animation, which was provided by and approved by brand already.

Michael Wu apparently has a patch ready to land.  Michael, please advise if you need anything to get this patch landed.
The patch has landed. I'm going to request approval to land this on aurora and beta. However, we'll also need to hand the vendor the animation and update the boot png on the gaia side.
Target Milestone: --- → B2G C2 (20nov-10dec)
"P1 blocker" means, "everyone drop what you're doing to fix this bug".
Severity: blocker → normal
(In reply to Michael Wu [:mwu] from comment #5)
> The patch has landed. I'm going to request approval to land this on aurora
> and beta. However, we'll also need to hand the vendor the animation and
> update the boot png on the gaia side.

Michael what can I do to help on the Gaia side?
Attached image Boot animation apng
On the gaia side, I replaced apps/system/resources/images/initlogo.png with this apng. I've also changed the css transition from ease to ease-out to make it faster, though I don't know how much of an effect it has.

This apng doesn't contain all the frames from the full boot animation. I didn't include all of them in order to keep the file size down. Unfortunately, it seems like we run out of frames before reaching the end of the animation.
Whiteboard: visual design → visual design UX-P1
(In reply to Michael Wu [:mwu] from comment #8)
> Created attachment 687848 [details]
> Boot animation apng
> 
> On the gaia side, I replaced apps/system/resources/images/initlogo.png with
> this apng. I've also changed the css transition from ease to ease-out to
> make it faster, though I don't know how much of an effect it has.
> 
> This apng doesn't contain all the frames from the full boot animation. I
> didn't include all of them in order to keep the file size down.
> Unfortunately, it seems like we run out of frames before reaching the end of
> the animation.

Did you meant to attach a patch?
(In reply to Vivien Nicolas (:vingtetun) from comment #9)
> (In reply to Michael Wu [:mwu] from comment #8)
> > Created attachment 687848 [details]
> > Boot animation apng
> > 
> > On the gaia side, I replaced apps/system/resources/images/initlogo.png with
> > this apng. I've also changed the css transition from ease to ease-out to
> > make it faster, though I don't know how much of an effect it has.
> > 
> > This apng doesn't contain all the frames from the full boot animation. I
> > didn't include all of them in order to keep the file size down.
> > Unfortunately, it seems like we run out of frames before reaching the end of
> > the animation.
> 
> Did you meant to attach a patch?

No - replacing initlogo.png was really the main thing. I did some things with the css transitions but I'm not sure if it makes a difference.
(In reply to Michael Wu [:mwu] from comment #10)
> (In reply to Vivien Nicolas (:vingtetun) from comment #9)
> > (In reply to Michael Wu [:mwu] from comment #8)
> > > Created attachment 687848 [details]
> > > Boot animation apng
> > > 
> > > On the gaia side, I replaced apps/system/resources/images/initlogo.png with
> > > this apng. I've also changed the css transition from ease to ease-out to
> > > make it faster, though I don't know how much of an effect it has.
> > > 
> > > This apng doesn't contain all the frames from the full boot animation. I
> > > didn't include all of them in order to keep the file size down.
> > > Unfortunately, it seems like we run out of frames before reaching the end of
> > > the animation.
> > 
> > Did you meant to attach a patch?
> 
> No - replacing initlogo.png was really the main thing. I did some things
> with the css transitions but I'm not sure if it makes a difference.

I think I'm trying to understand what left in order to close this bug. Sorry if this is obvious and I missed it :/
Does the only thing to do is to replace the current initlogo.png in Gaia by the image you provide?
Flags: needinfo?(mwu)
(In reply to Vivien Nicolas (:vingtetun) from comment #12)
> Does the only thing to do is to replace the current initlogo.png in Gaia by
> the image you provide?

For the gaia side, yes. It's not optimal though - we might be able to make it run smoother/faster.
Flags: needinfo?(mwu)
Here is the part that can be done for Gaia: https://github.com/vingtetun/gaia/commit/a46642d63039f7f4e0363ae25c14b15fb9e9c34c

But I guess this is not enough to close this bug. Should the bootanimation.zip file should be part of this bug too? How do we handle the time between bootanimation.zip and Gaia?
(In reply to Vivien Nicolas (:vingtetun) from comment #14)
> But I guess this is not enough to close this bug. Should the
> bootanimation.zip file should be part of this bug too?

I don't think so. We can put it in our device builds I guess, but it sounds like branding doesn't want that on dogfooding devices. We should pass it to our friends.

> How do we handle the time between bootanimation.zip and Gaia?

The boot animation doesn't stop until gaia is ready to take over. Once it's ready, a notification is sent from the B2G app that tells the widget layer it can start drawing for real.
I'm going to tie up the loose ends here today and close this.
Assignee: pla → mwu
The boot animation has been landed in gonk-misc and disabled by default. Our friends will turn it on for their own builds.

Vingtetun, can you land the gaia side and close this bug?
Is there a r+'d patch ready to merge?
(In reply to Chris Jones [:cjones] [:warhammer] from comment #18)
> Is there a r+'d patch ready to merge?

There's a commit on vingetun's repo but no pull request that I can see.
So the code looks fine and works well, but it includes the branded resource I thought our folks didn't want to include in pre-production builds.

Do we have a placeholder graphic we can use?
Flags: needinfo?(mwu)
If you're talking about the one in gaia, there's already a placeholder there. It's that white mozilla text at the bottom right. If you're talking about the bootanimation.zip, it's disabled by default. I can put together a placeholder boot animation, but it works fine without it - it just shows a black screen till things are ready.
Flags: needinfo?(mwu)
OK, then that's the only thing that needs to be changed in vingtetun's patch.
Flags: needinfo?(pla)
I will try to turn it off by default tomorrow and land my changes.
Attached patch PatchSplinter Review
I have change a throw new Error to a dump in the build/webapps-zip.js file because there is an error in the code that parse the html to find shared/ file to load. It seems like it reads code of inline css (background: #000 url('shared/resources/branding/initlogo.png') bottom right no-repeat;) as well as commented code :/

I will open a followup for that.
Attachment #690509 - Flags: review?(jones.chris.g)
Attachment #690509 - Flags: review?(jones.chris.g) → review+
Whiteboard: visual design UX-P1 → visual design UX-P1, QARegressExclude
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: