1169879 - Use only the critical displayport when computing image visibility

Status: RESOLVED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[Seth Fowler [:seth] [:s2h]]

Currently PresShell::MarkImagesInSubtreeVisible(), which is used to compute which images are visible, bases its calculations on the displayport for any nsIScrollableFrame which has one. It uses nsLayoutUtils::GetDisplayPort() to determine the displayport of the scrollable frame.

The problem is that GetDisplayPort() returns the full displayport - the one used for painting low-precision buffers - and not the critical displayport. The full displayport can be *huge* when gfxPrefs::UseLowPrecisionBuffer() is enabled. When scrolling, it can easily be well over 10,000 CSS pixels in height, and even when stationary it's still thousands of CSS pixels high. This is compounded by the fact that we may triple the size of whatever GetDisplayPort() returns (via ExpandRectToNearlyVisible).

The result is that we end up considering most or all of the thumbnails in the B2G Gallery app visible, even with huge numbers of images in the Gallery.

We need to fix this ASAP, as it's causing serious issues on B2G. Long term, I'd like to explore a notion of image locking that would interact with things like the low resolution displayport better - I have some ideas, but they're not fully baked yet. But in the short term, I think it's clear that the best option is to only lock inside the critical displayport. We will still lock images in the low-res displayport *while we're drawing it*, because they'll get locked via OnUnlockedDraw(). But we'll unlock those images very quickly, as soon as we recompute image visibility, and I think that's for the best until we have a better solution in place.

Comment 1

[Seth Fowler [:seth] [:s2h]]

Attachment: Use only the critical displayport when computing image visibility

Here's the patch.

Again, we can explore better ways to integrate the low-res displayport with
image locking in the future. But for now we need to make this change to make
things sane again and fix the image-locking-related memory issues that B2G is
currently experiencing.

Comment 2

[Seth Fowler [:seth] [:s2h]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b1658a7478a3

Comment 3

[Seth Fowler [:seth] [:s2h]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/78a8270c230e

Comment 4

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/78a8270c230e

Comment 5

[Seth Fowler [:seth] [:s2h]]

Comment on attachment 8613199 [details] [diff] [review]
Use only the critical displayport when computing image visibility

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not sure, but it was exposed by the fact that we enabled image locking on B2G in bug 1148696.
User impact if declined: Images may fail to decode due to low memory, causing blank thumbnails in the gallery which may persist across reboots (making this effectively a data loss issue). This patch is one of several that together fix bug 1166136, which is nominated for blocking 2.2, and bug 1164164, which is a 2.2 blocker.
Testing completed: Extensively tested locally. On mozilla-central.
Risk to taking this patch (and alternatives if risky): This is a very simple, low risk patch.
String or UUID changes made by this patch: None.

Comment 6

[Josh Cheng [:josh]]

2.2+ as this causing function broken for Gallery app.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/1f88b045ac6c