1259278 - Implement precise visibility tracking using the same display lists that we paint with

Status: REOPENED

(Core :: Layout, task)

Description

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

Especially given that we only update approximate visibility at most once per second, we need to combine approximate visibility tracking with precise visibility tracking. We need both, because approximate visibility tracking is used for predictive image decoding and tracks an area which is larger than the viewport or displayport (this is why it is approximate), but the low sample rate for it makes it poorly suited for many things that we'd want to use visibility tracking for.

Here's the initial plan:

(1) Add a second frame visibility counter (stored in the same frame property; we should still be able to avoid allocation by being smart about the number of bits we use). This counter will be used for precise visibility.

(2) Add a second set to the pres shell for precisely visible frames.

(3) When we construct a display list for painting, increment the precise visibility count for frames in the display list, and decrement for frames that are no longer visible, using the same algorithm we use for approximate visibility. Note that display lists constructed for other purposes (e.g. canvas.drawWindow()) should not be factored in, and we should also probably ignore display lists intended for painting the low-resolution displayport we use when scrolling quickly.

(4) Add a new Visibility::VISIBLE enum value, and rename Visibility::APPROXIMATELY_NONVISIBLE to Visibility::NONVISIBLE.

(5) nsIFrame::GetVisibility() should return Visibility::VISIBLE if the precise visibility counter for the frame is greater than 0, else Visibility::APPROXIMATELY_VISIBLE if the approximate visibility counter is greater than 0, else Visibility::NONVISIBLE.

(6) Update the other visibility-related methods to be precise visibility-aware.

(7) Remove now-unnecessary code. One obvious candidate is nsIFrame::UpdateVisibilitySynchronously() and all callers.

(8) Update the visibility visualization to paint precisely-visible regions a different color from approximately-visible regions. (Which requires sending them over to the compositor thread separately.)

These changes shouldn't be that complex, and they should make the visibility API much more useful.

CC'ing some folks familiar with this code.

Comment 1

[Tobias Schneider [:tobytailor]]

Attachment: Part 1: Add Visibility::IN_VIEWPORT to the frame visibility API

Comment 2

[Tobias Schneider [:tobytailor]]

Attachment: Part 2: Cache the current scroll parent and scrollports/displayports information

Comment 3

[Tobias Schneider [:tobytailor]]

Attachment: Part 3: Only consider a frame IN_DISPLAYPORT if it's within the critical displayport

Comment 4

[Tobias Schneider [:tobytailor]]

Attachment: Part 4: Fix switch block compiling errors on Android

Comment 5

[Tobias Schneider [:tobytailor]]

Attachment: Part 5: Add lambda versions of nsIDocument::EnumerateSubDocuments()

Comment 6

[Tobias Schneider [:tobytailor]]

Attachment: Part 6: Replace remove-only approximate visibility updates with just dropping everything outside of the viewport

Comment 7

[Tobias Schneider [:tobytailor]]

Most of the patches are rebased versions of patches from bugs 1270389, 1272554 and 1270394 to keep them updated in a single bug.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 9

[Sylvestre Ledru [:Sylvestre]]

No activity for years, closing. please reopen if you plan to finish it