1047826 - Statusbar performance warning

Status: RESOLVED WONTFIX

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

Description

[:gerard-majax]

Reproduced with my current Nexus S running master:

> 08-02 12:11:53.166  3631  3631 I Gecko   : Performance warning: Async animation disabled because frame size (320, 76) is bigger than the viewport (360, 34) [div with id 'statusbar']

I'm wondering if it may be a recent regression or just that we have new code to detect this.

Comment 1

[Michael Henretty [:mikehenrty][:mhenretty]]

I spoke with :roc about this problem on IRC, and he said that the warning is there to prevent people from trying to animate a huge element which is largely obscured by its container. He said for our use case, he would be willing to relax the heuristics in the platform, since we aren't talking about many pixels here.

Comment 2

[Kevin Grandon :kgrandon]

But why do we see this warning for the statusbar, but not for example panels that slide in/out of apps? The statusbar is much smaller than the panels in apps, and I believe they both use translate() to position content.

Comment 3

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Kevin Grandon :kgrandon from comment #2)
> But why do we see this warning for the statusbar, but not for example panels
> that slide in/out of apps? The statusbar is much smaller than the panels in
> apps, and I believe they both use translate() to position content.

It depends on the size of the element in both width and height.

IIRC correctly the rules to get the fast path are:
If (element.width <= (screen.width + 1/8 * screen.width)) && (element.height <= (screen.height + 1/8 * screen.height))

If any of those conditions is false, then we get out of the fast path.

Comment 4

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

(In reply to Michael Henretty [:mhenretty] from comment #1)
> I spoke with :roc about this problem on IRC, and he said that the warning is
> there to prevent people from trying to animate a huge element which is
> largely obscured by its container. He said for our use case, he would be
> willing to relax the heuristics in the platform, since we aren't talking
> about many pixels here.

hmm. I'm not sure it makes sense to relax the heuristic at that point. Most of our codes relies on it and it prevent some mistakes. For example why does the statusbar get out of the optimization code path ? Pretty sure it does not make sense that any of its dimensions are way bigger than one of the screen dimension.

Comment 5

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

So in case this is not clear, I like this warning, it has let me caught some regressions in the past. Like bug 1028216 for example...

Comment 6

[BMO Automation]

Firefox OS is not being worked on