Closed Bug 790509 Opened 12 years ago Closed 12 years ago

First app-opening animation for in-process apps is slow (~15fps)

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 790508

People

(Reporter: cjones, Assigned: dzbarsky)

References

Details

This only happens with
 - opening in-process apps
 - with out-of-process homescreen
 - only the first time, when the app is actually launched

Subsequent animations are back up at 60fps where they belong.

Sadly, we do care about this because the browser app will in-process for v1.

This is very strange indeed; possibly related to bug 790508.
It looks like the app's frame is getting ColorLayer-ized, so I can't tell with paint flashing whether we're invalidating it or not.

There aren't any slow-animation warnings.  Hmmm...
If I slow down the individual segments of the animation to 5s, then what I see is
 - it runs like crap for a second or so
 - but then gets up to ~60fps after that

If I had to guess, it appears that the app's loading itself is somehow interfering with the animation.  Since the animation is supposed to run on the compositor thread, that's not supposed to be possible.
OK, so it looks like the animation logging is lying to me, or not dumping to logcat.  We *aren't* asyncing the app-opening animation.
nsLayoutUtils::IsAnimationLoggingEnabled() is saying "yes", but I don't get anything in logcat.  Hmmm....
The problem is that all the checks are passing, so the logging code doesn't know that the animation was blackballed, but something is indeed blackballing it.  Missed a spot :) (or two).
Assignee: nobody → dzbarsky
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.