1041608 - Getting stuck in low res tiling mode

Status: RESOLVED DUPLICATE of bug 1041200

(Core :: Layout, defect)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: What homescreen looks like

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.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

No-Jun, do you see this on 2.0?

Comment 2

[Milan Sreckovic [:milan] (needinfo for best results)]

Attachment: What settings looks like

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I see this on my Hamachi running code from this morning.

Comment 4

[Kartikaya Gupta (email:[e-mail])]

Bisecting using mozilla-inbound-flame-eng builds gave me:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9350909a3401&tochange=e6b5084690dc

Comment 5

[Kartikaya Gupta (email:[e-mail])]

I'll do local builds to narrow it down further.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Attachment: Layer tree dump of the homescreen with part 20

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.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Layer tree dump of the homescreen at part 19

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?

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Sorry, it's not that there's a ContainerLayerComposite *instead of* a ColorLayerComposite. There's just an extra empty ContainerLayerComposite after part 20.

Comment 11

[Mason Chang [Inactive] [:mchang]]

I just bisected and got this:

hg bisect -b
The first bad revision is:
changeset:   195159:bc0968c1d061
user:        Robert O'Callahan <[e-mail]>
date:        Mon Jun 23 16:24:00 2014 +1200
summary:     Bug 1022612. Part 31: Perform layer-level occlusion culling in FrameLayerBuilder. r=mattwoodrow

Comment 12

[Timothy Nikkel (:tnikkel)]

Attachment: flatten display items that have no children too (ie scroll info layers)

Haven't looked over the computevis changes yet, but this seems to be a problem.

Comment 13

[Timothy Nikkel (:tnikkel)]

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.

Comment 14

[Timothy Nikkel (:tnikkel)]

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.

Comment 15

[Timothy Nikkel (:tnikkel)]

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).

Comment 16

[Timothy Nikkel (:tnikkel)]

Attachment: Move scroll info layer to be on top of scrolled content, not below it

I just re-used the same hack we use for scrollbars so the scroll info layer doesn't get moved too far up.

Comment 17

[Timothy Nikkel (:tnikkel)]

These patches seem to fix bug 1041510, but not this bug. So moving them there.

Comment 18

[Kartikaya Gupta (email:[e-mail])]

Attachment: Client-side layer dump after bug 1041510

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.

Comment 19

[Kartikaya Gupta (email:[e-mail])]

As far as I can tell this is still a layout side problem. More details in a sec.

Comment 20

[Kartikaya Gupta (email:[e-mail])]

Attachment: More info dumps

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.

Comment 21

[Timothy Nikkel (:tnikkel)]

There is a good chance that bug 1041200 fixed the problem, just need to verify.

Comment 22

[Kartikaya Gupta (email:[e-mail])]

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.