814322 - Window manager unnecessarily waits 100ms before loading the windows of newly-opened apps

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Make sure calculator app is closed
 (2) Tap calculator icon to launch it

There seems to be a delay before it's launched, but that might be my imagination.

However, if we *are* waiting for the "nextpaint" delay for newly opened frames, we shouldn't be; that only hurts startup time.

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

You are right -- openWindow() currently opens window without finding out if the frame is just created or not.

It should not wait for 100ms if |unpaint| state is set on the frame.

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #1)
> It should not wait for 100ms if |unpaint| state is set on the frame.

You're talking about the setTimeout(, kTransitionWait), right? We shouldn't need this when showing a newly created frame.

Also, why do we wait 100ms when opening a frame at all? Bug 808231 is only about app -> homescreen transitions, isn't it?

Comment 3

[Tim Taubert [:ttaubert] (inactive)]

This will be fixed by bug 808231.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Tim Taubert [:ttaubert] from comment #2)
> (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #1)
> > It should not wait for 100ms if |unpaint| state is set on the frame.
> 
> You're talking about the setTimeout(, kTransitionWait), right? We shouldn't
> need this when showing a newly created frame.

Yes.

> Also, why do we wait 100ms when opening a frame at all? Bug 808231 is only
> about app -> homescreen transitions, isn't it?

When a frame is being put to background, we will call |setVisible(false)| on the mozbrowser iframe. The video buffer of the OOP iframe will be cleaned up, resulting an white/transparent iframe. Every time we make the iframe visible again we will need to wait for 100ms after calling |setVisible(true)| so the user will not see the white iframe. This apply to both app -> homescreen and homescreen -> app transitions, since hidden homescreen and the closed iframe will be |setVisible(false)|'d when it's ... not visible.

cjones will have better idea to explain this.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

100ms is the current "timeout" for awaiting the repaint.  The "nextpaint" event is the "real fix" for waiting for the repaint, *but* ... we still need a timeout, because we can't wait arbitrarily long on apps before starting the UI transition.  However, with "nextpaint", the timeout can be higher.

We had hoped the timeout would work well enough, but based on experience and the bugs that are being filed, it appears we want "nextpaint" after all.

Comment 6

[Tim Taubert [:ttaubert] (inactive)]

Thank you both for clarifying. That's exactly how I'm currently implementing it.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Chris,

I don't think bug 814771 has anything to do with this one. This one is about the homescreen -> newly launched app transition, and that one was about app -> homescreen.

Comment 8

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

Fixed by bug 808231.