Closed Bug 795322 Opened 12 years ago Closed 12 years ago

Over-invalidation on everything.me results pages

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 799956
Project Flags:
blocking-basecamp +

People

(Reporter: cjones, Assigned: cjones)

References

Details

The gaia code just landed today, so I didn't have a chance to test before dlbi landed.

STR
 (1) In b2g, swipe to the left to enter everything.me page.
 (2) Hold down finger and swipe up and down in icons view

In http://hg.mozilla.org/integration/mozilla-inbound/rev/9f476b4ac1e1, we don't invalidate the set of icons while they're being panned around.  With https://hg.mozilla.org/integration/mozilla-inbound/rev/84e550d568ce we invalidate the whole page on each move, and perf suffers considerably.

No guesses what's up yet.
DLBI should make it fairly easy to debug invalidations.

You want to define 'DEBUG_INVALIDATIONS' in both nsViewManager.cpp, and FrameLayerBuilder.cpp in a debug build.

It should then dump all the display items that get invalidated (and the region invalidated) for each paint, and why they were invalidated.

The only hard part can be matching up paints you saw with the log output.

I can help interpret one of these logs if needed.
Summary: Invalidation (?) regression on everything.me results pages → Over-invalidation on everything.me results pages
cjones, should this be a blocker?
blocking-basecamp: --- → ?
IMHO, it definitely is.
An element on the homescreen has gone from 40-60fps to ~10fps overnight.
Yes, this is prime real estate.
blocking-basecamp: ? → +
What's going on here is

---- PAINT START ----PresShell(0x4319c620), nsView(0x44321880), nsIWidget(0x4303e110)
Display item type nsDisplayTransform(0x44868ea0) (in layer 0x4501b800) changed geometry!
Invalidating layer 0x4501b800: < (x=-4, y=77, w=324, h=335); >
Display item type nsDisplayTransform(0x448697f8) (in layer 0x44043a40) changed geometry!
Invalidating layer 0x44043a40: < (x=0, y=17, w=322, h=395); >
Inactive LayerManager(0x449b2800) for display item nsDisplayTransform(0x448697f8) has an invalid region - invalidating layer 0x44043a40
Invalidating layer 0x44043a40: < (x=12, y=30, w=293, h=373); >
Inactive LayerManager(0x4491a500) for display item nsDisplayTransform(0x44868ea0) has an invalid region - invalidating layer 0x4501b800
Invalidating layer 0x4501b800: < (x=-4, y=17, w=326, h=395); >
---- PAINT END ----

Chasing down the "changed geometry!" part of this ...
Matt points out that these transforms only show up in this logging when they're inactive, which is odd in this case.

---- PAINT START ----PresShell(0x4319c620), nsView(0x44521940), nsIWidget(0x4303e110)
Display item type nsDisplayTransform(0x449cac68) (in layer 0x43ee7400) for element <div id="page-categories"> changed geometry!
Invalidating layer 0x43ee7400: < (x=-4, y=77, w=324, h=380); >
Display item type nsDisplayTransform(0x449cb5c0) (in layer 0x44443850) for element <ul id="shortcuts-items"> changed geometry!
Invalidating layer 0x44443850: < (x=0, y=72, w=322, h=385); >
Inactive LayerManager(0x449d5c00) for display item nsDisplayTransform(0x449cb5c0) has an invalid region - invalidating layer 0x44443850
Invalidating layer 0x44443850: < (x=12, y=85, w=293, h=363); >
Inactive LayerManager(0x449d5000) for display item nsDisplayTransform(0x449cac68) has an invalid region - invalidating layer 0x43ee7400
Invalidating layer 0x43ee7400: < (x=-4, y=72, w=326, h=385); >
---- PAINT END ----

Much better --- it's <div id="page-categories"> and <ul id="shortcuts-items"> that are involved here.
Forcing-on the logging in

http://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#3641

shows a few more frames involved here.  The full list is

 - <div id="page-categories">
 - <ul id="shortcuts-items">
 - <footer id="footer">
 - <div id="evmePage">
 - <ul id="evmeAppsList">
 - <div (no id)>, which is one or more divs without "id" attributes

Comment 7 didn't reveal enough info for me to find the relevant code here, but this looks more promising.
This is marked blocking already, this is a core piece of the App/content discovery experience. 

cjones, who's a good person to take this on?
Assignee: nobody → jones.chris.g
Ran / Vivien, I'm having some trouble tracking down the code responsible for panning these elements around.  Can you give me a pointer?
Hey Chris, we use iScroll (modifies transform value of ul#shortcuts-items)
The script can be found in /apps/homescreen/everything.me/js/external/iscroll.js
This magically went away!  We're up to 60fps in latest builds.

There weren't any e.me code changes landed recently, right?

Going to track down the appropriate dup ...
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Chris, I've just flashed the latest (15th Oct) backend and unfortunately I don't see an improvement. Still on 9fps.
Notice every touchmove triggers a repaint.

Try flashing the device with 18th Sep backend (and then make latest gaia master) - you can see 40-60fps and no repaint on touchmove.
Another thing I've noticed is that now, the shortcut icons scrolling is quite screwed up - hardly moves at all.
Though if you click a shortcut icon, scrolling the resulted apps is possible as before.

(No changes in Evme have been merged in to master for quite a long time)
Hi Ran,

This fix was only just merged into our upstream repository (30 mins ago).  The nightly b2g builds are now built off our stable repository (mozilla-aurora), so the fix will additionally need to be uplifted to there.  You may not see this in nightly builds for another day or two :(.
Got it. Waiting patiently :)
Works awesome!
You need to log in before you can comment on or make changes to this bug.