1033371 - Tiles often don't update correctly immediately after navigation or page size changes

Status: RESOLVED WORKSFORME

(Core :: Panning and Zooming, defect)

Description

[Chris Lord [:cwiiis]]

Attachment: Screenshot

STR:

1. Load and log into twitter.
2. Scroll down a bit (not always necessary) and select a tweet
3. Go back using the back button in the top-left

Expected:

Twitter goes back, renders correctly.

Actual:

Sometimes the display is partially or entirely rendered in low-precision. Scrolling immediately corrects the rendering.



This is where I see it the most, but I often see it in these other situations:

- Press the 'more' button in the apps list of the marketplace
- Scrolling down on the Facebook news feed fast enough to reach and stop at the spinner that indicates more content is loaded (whereby the re-render after the content comes in won't happen correctly)
- Choose a tweet or twitter avatar in Twitter, often the resulting page is partially rendered


I suspect that layers are getting incorrect FrameMetrics at some point, with respect to scroll position and/or composition bounds. Possibly on the first-paint.

Screenshot attached.

Flagging qawanted to see if this happens in 2.0 (I'm running on central, but I suspect the issue is there too).

Comment 1

[Chris Lord [:cwiiis]]

Note, that although you don't always get it to settle with the low-precision tiles visible, I do almost always seem them at least flicker on before being visible redrawn - this is an indication of a bug, as the coherency checks ought to make sure that visible tiled updates happen in a single batch.

Comment 3

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

Can you let me know if you're still seeing this on the latest master code? Bug 1027851 and its dependencies should have fixed a few more cases where this scenario happens.

Comment 4

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #3)
> Can you let me know if you're still seeing this on the latest master code?
> Bug 1027851 and its dependencies should have fixed a few more cases where
> this scenario happens.

I can't (yet) reproduce low-precision content staying on the screen until a forced update, and it generally seems much better.

On the other hand, I can still repeat low-precision content being visible without any async scrolling in Twitter. If I go to a tweet, then use the in-app back button in the top-left to go back to the feed, I often see it render in low precision before quickly updating at high-precision.

As I understand it, this shouldn't be possible (rather, it's unintended - it's obviously possible :)) - you should only ever see low-precision content in response to async scrolling and not page-triggered updates(?) Please correct me if this is a bad assumption.

I'll update here if I reproduce anything more serious, but this is looking much better than it was when I reported the issue.

Comment 5

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

(In reply to Chris Lord [:cwiiis] from comment #4)
> On the other hand, I can still repeat low-precision content being visible
> without any async scrolling in Twitter. If I go to a tweet, then use the
> in-app back button in the top-left to go back to the feed, I often see it
> render in low precision before quickly updating at high-precision.
> 
> As I understand it, this shouldn't be possible (rather, it's unintended -
> it's obviously possible :)) - you should only ever see low-precision content
> in response to async scrolling and not page-triggered updates(?) Please
> correct me if this is a bad assumption.

I think this is intentional. I've seen the same behaviour in the settings and contacts apps in Gaia. I believe it's because the content is CSS transform'd out of the way, and so it ends up in the low-res displayport. When it's transformed in that's what gets drawn (instead of checkerboarding) and then once things are stable it gets drawn in high-res again. I haven't looked into this in detail though. If this is an actual problem I'd rather file a separate bug for it (one that's not marked 2.0+) because it seems much less severe.

Comment 6

[Chris Lord [:cwiiis]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #5)
> (In reply to Chris Lord [:cwiiis] from comment #4)
> > On the other hand, I can still repeat low-precision content being visible
> > without any async scrolling in Twitter. If I go to a tweet, then use the
> > in-app back button in the top-left to go back to the feed, I often see it
> > render in low precision before quickly updating at high-precision.
> > 
> > As I understand it, this shouldn't be possible (rather, it's unintended -
> > it's obviously possible :)) - you should only ever see low-precision content
> > in response to async scrolling and not page-triggered updates(?) Please
> > correct me if this is a bad assumption.
> 
> I think this is intentional. I've seen the same behaviour in the settings
> and contacts apps in Gaia. I believe it's because the content is CSS
> transform'd out of the way, and so it ends up in the low-res displayport.
> When it's transformed in that's what gets drawn (instead of checkerboarding)
> and then once things are stable it gets drawn in high-res again. I haven't
> looked into this in detail though. If this is an actual problem I'd rather
> file a separate bug for it (one that's not marked 2.0+) because it seems
> much less severe.

I'm pretty certain the Twitter website doesn't work like this, but without a reduced test-case and reliable STR, it's going to be pretty hard to track down. I'll file a bug if it turns out to be more commonplace/annoying than it initially seems.

Comment 7

[Chris Lord [:cwiiis]]

Ok nope, this happens just as badly as it did before, but for some reason, the frequency is lower. Possibly some other unrelated change is causing more draws to get triggered, but after 24 hours, I've managed to multiple times be stuck in an inconsistent state (until triggering a draw).

This happens most frequently, still, when going back after selecting a tweet from the feed in the official Twitter app (which is just their mobile site), and also when loading Facebook, where often the final composite doesn't happen and you're left looking at an incomplete rendering of the page (either missing images, weird incomplete layout, or both).

Comment 8

[Ben Kelly [:bkelly, not reviewing]]

Personally, I see this trigger more often on Open C than Flame.

Comment 9

[Chris Lord [:cwiiis]]

(In reply to Ben Kelly [:bkelly] from comment #8)
> Personally, I see this trigger more often on Open C than Flame.

I think this is more likely coincidence than anything, but the Open C does only have 512mb ram (vs 1gb on the Flame)... I doubt this is related to memory pressure, but perhaps different performance profiles when under memory pressure?

Comment 10

[Ben Kelly [:bkelly, not reviewing]]

The Open C also has a smaller screen, so fewer pixels to push.  I guess just different timing in some race?

Comment 11

[Chris Lord [:cwiiis]]

(In reply to Ben Kelly [:bkelly] from comment #10)
> The Open C also has a smaller screen, so fewer pixels to push.  I guess just
> different timing in some race?

The Open C has the same resolution as the Flame - they're pretty much identical, except the RAM (well, and the cameras, proximity sensor and light sensor).

Comment 12

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

Forget 512mb and 1024mb :), this should be tested with 256mb (273mb for obscure reasons) Flame.  If you set it up:
boot into fastboot mode
fastboot oem mem 273
fastboot reboot

does this reproduce at this configuration?

Comment 13

[Chris Lord [:cwiiis]]

(In reply to Milan Sreckovic [:milan] from comment #12)
> Forget 512mb and 1024mb :), this should be tested with 256mb (273mb for
> obscure reasons) Flame.  If you set it up:
> boot into fastboot mode
> fastboot oem mem 273
> fastboot reboot
> 
> does this reproduce at this configuration?

Assuming that Twitter doesn't just crash under these conditions, there's no reason it wouldn't. We've gotten side-tracked here, this issue has nothing to do with available memory (of this, I'm 99% certain).

Comment 14

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

Might be fixed by the patches on bug 1027593 where I found yet another case that results in AboutToCheckerboard returning true instead of false.

Comment 15

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

Triage again, given comment 4, comment 5, comment 7.  I'm not sure we're still tracking the same bug and with the same importance, so better if we are explicit about this (new one?) is also actually a blocker.  We can see if bug 1027593 is a dupe, but we should evaluate if this is a blocker or not independently of what the fix would be.

Comment 16

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

Chris, there are patches on bug 1027593 - can you see if those fix the twitter issue?

Comment 17

[Chris Lord [:cwiiis]]

I'm running central on my phone again (git commit 51ac93f62dfaba70de71610bbc14e0b62d7e0525, updated my tree yesterday night (so about 24 hours ago) - This includes the fixes in bug 1027593 and various others.

I'll resolve this bug if I feel confident it's disappeared - it's not always easy to trigger, but I should know within a day.

Comment 18

[bhavana bajaj [:bajaj]]

(In reply to Chris Lord [:cwiiis] from comment #17)
> I'm running central on my phone again (git commit
> 51ac93f62dfaba70de71610bbc14e0b62d7e0525, updated my tree yesterday night
> (so about 24 hours ago) - This includes the fixes in bug 1027593 and various
> others.
> 
> I'll resolve this bug if I feel confident it's disappeared - it's not always
> easy to trigger, but I should know within a day.

Clearing the nom, if you hit this again feel free to renom.

Comment 19

[Chris Lord [:cwiiis]]

I haven't managed to reproduce this in regular-ish use. I'm not using my phone quite as much these past couple of days than I do normally, but I've not hit this.

I am still seeing brief screens of low-precision, which I still don't think is right, but it doesn't persist.

I am seeing blank flickers in my testing of home-screen bits (around layer creation/destruction), so there are still issues, but perhaps this bug isn't useful for that and we should open new bugs specific to particular issues now.

So all that said, closing this and I'll reopen bugs with specific cases.