Closed Bug 1041608 Opened 6 years ago Closed 6 years ago
Getting stuck in low res tiling mode
3.00 MB, image/jpeg
829.83 KB, image/jpeg
4.48 KB, text/plain
4.00 KB, text/plain
1.68 KB, text/plain
39.96 KB, text/plain
Install latest engineering trunk daily (July 21st). Scroll to the bottom of the home screen - the icons stay in low res mode. I also saw this in the settings app.
No-Jun, do you see this on 2.0?
Assignee: nobody → bugmail.mozilla
6 years ago
Attachment #8459660 - Attachment description: What it looks like → What homescreen looks like
I see this on my Hamachi running code from this morning.
Bisecting using mozilla-inbound-flame-eng builds gave me: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9350909a3401&tochange=e6b5084690dc
I'll do local builds to narrow it down further.
Looks like it was caused by https://hg.mozilla.org/integration/mozilla-inbound/rev/2b0d786121d4. The STR are simply to build b2g, and scroll up and down on the homescreen. Usually just scrolling down the first time will trigger it, but sometimes it doesn't - in those cases scrolling back up and down does it.
This is what the layer tree dump of the homescreen looks like after part #20 is applied. Note that there are two ContainerLayerComposite instances (0xacd31c00 and 0xacd32000) where there should only be one. Both of these correspond to the content with scrolId=4 and have the same metrics. I strongly suspect this is related.
Attachment #8459729 - Attachment description: Layer tree dump of the homescreen → Layer tree dump of the homescreen with part 20
At part 19, there is a ColorLayerComposite instead of a ContainerLayerComposite, and everything works just fine. roc, do you know what's going wrong here?
Sorry, it's not that there's a ContainerLayerComposite *instead of* a ColorLayerComposite. There's just an extra empty ContainerLayerComposite after part 20.
Duplicate of this bug: 1042010
I just bisected and got this: hg bisect -b The first bad revision is: changeset: 195159:bc0968c1d061 user: Robert O'Callahan <email@example.com> date: Mon Jun 23 16:24:00 2014 +1200 summary: Bug 1022612. Part 31: Perform layer-level occlusion culling in FrameLayerBuilder. r=mattwoodrow
Whiteboard: [c=regression p= s= u=2.0]
See Also: → 1041510
Haven't looked over the computevis changes yet, but this seems to be a problem.
Assignee: bugmail.mozilla → tnikkel
Attachment #8460382 - Flags: review?(roc)
Comment on attachment 8460382 [details] [diff] [review] flatten display items that have no children too (ie scroll info layers) This apparently isn't enough to get the scroll info layer to flatten, but it's certainly necessary.
The remaining problem is that doing the merging and flattening for scroll items in ProcessDisplayItems means we do it from bottom to top, whereas ComputeVisibility did it from top to bottom. We were depending on merging flattening all scroll layer items before the scroll info layer item. The scroll info layer items needs to know the result of the merging and flattening of the scroll layer items so it knows if it should stick around or get flattened.
Based on kats suggestion I guess the easiest way to fix that is to just move the scroll info layer so it is still processed last (ie move it to be on top of the other scrolled content).
I just re-used the same hack we use for scrollbars so the scroll info layer doesn't get moved too far up.
These patches seem to fix bug 1041510, but not this bug. So moving them there.
Assignee: tnikkel → bugmail.mozilla
The patches on bug 1041510 fix the layer tree problems I described above, and are a pre-requisite to this bug. However it doesn't fix the problem entirely. Now when I scroll down on the homescreen I see a client-side layer dump that looks like the attached. The problem (I think) is that the scrollable container layer is marked [not visible] and so it doesn't get rendered.
As far as I can tell this is still a layout side problem. More details in a sec.
Component: Panning and Zooming → Layout
The problem as I mentioned in the last comment is that the container layer ends up having an empty visible rect when I'm scrolled down to the bottom of the homescreen. In fact the visible rect is empty when the scroll offset is y > 537. The first part of the attached dump shows how the visible region gets shorter and shorter as I scroll down. The second part of the attached dump shows the display list and client-side layers dump at scroll offset y=419, when the visible region has been shortened but hasn't disappeared entirely. I don't really understand how the visible region is computed but it looks like even on the display list item it looks like the visible region is 537. I would maybe expect it to be the height of the displayport? I'm not really sure what it's supposed to be at this point.
There is a good chance that bug 1041200 fixed the problem, just need to verify.
Indeed, bug 1041200 seems to have fixed this. A B2G master build from m-c cset e5ced39f443b didn't have this bug, and when I backed out 1041200 locally it came back. Duping this over.
Status: NEW → RESOLVED
Closed: 6 years ago
No longer depends on: 1041510
Resolution: --- → DUPLICATE
Duplicate of bug: 1041200
You need to log in before you can comment on or make changes to this bug.