Use the most recent visibility value for on demand visibility requests [chromium/src : main]

0 views
Skip to first unread message

Benjamin Keen (Gerrit)

unread,
Jul 25, 2024, 1:22:47 AM (2 days ago) Jul 25
to Stefan Zager, Chromium LUCI CQ, chromium...@chromium.org, srirama chandra sekhar, blink-re...@chromium.org, blink-revi...@chromium.org, blink-rev...@chromium.org, blink-...@chromium.org, eric.c...@apple.com, feature-me...@chromium.org, kinuko...@chromium.org
Attention needed from Frank Liberato

Benjamin Keen added 1 comment

File third_party/blink/renderer/core/html/media/media_video_visibility_tracker.cc
Line 651, Patchset 1: tracker_attached_to_document_->GetFrame()->View()->UpdateAllLifecyclePhases(
Stefan Zager . resolved

This is a very heavy hammer that is reserved for very special cases.

IIUC, this is meant to address the case where the tab containing this video element is backgrounded due to tab switching. In that case, is it actually necessary to compute occlusion, since the video element is known to be completely hidden?

Benjamin Keen

IIUC, this is meant to address the case where the tab containing this video element is backgrounded due to tab switching

That is correct.

Is it actually necessary to compute occlusion, since the video element is known to be completely hidden?

Yes. Since we are implementing notifications using a pull model. What this means is that when the user switches tab, that's when we will ask for video visibility.

We are interested in the video visibility just after the user switches tab. After that, we won't continue to compute visibility. The problem I'm running into, is that if the `LifecycleState` is not clean at the time the user switches tab, the lifecycle will not be updated (since the tab is backgrounded), and therefore the visibility computation will not take place.

The reasoning for using this notification model is to avoid performing this expensive computation as much as possible. After all, we only care about visibility when the user switches tab.

Do you know if there are other, less invasive, alternatives?

Stefan Zager

If the tab containing the video is backgrounded, why can't you just unconditionally report the video "not visible" and be done with it?

Benjamin Keen

Hmmm, if the document is not in a clean lifecycle state at the moment we switch tabs, then we will report the video as not visible, regardless of its actual visibility. Unless I'm misunderstanding something?

Stefan Zager

If the document is backgrounded, then the video element is by definition not visible. Am *I* missing something?

Benjamin Keen

To recap our offline conversation, this approach is not feasible since painting a backgrounded tab will introduce potential problems.

Stefan suggested an alternative solution: keep continuously computing visibility and caching the value (perhaps at a lower frequency every x seconds). And instead of storing the `request_visibility_callback_` to be run later, just return the cached value if the document is not in the `kPaintClean` state.

@libe...@chromium.org WDYT? This would defeat the goal of computing visibility only when we switch tabs, but seems to be the best we can do.

Stefan Zager

Just to add some context: the strategy of periodically computing something rendering-dependent and then using the most-recently-computed value as needed is idiomatic in blink. While it is possible that the value might be stale when used, generally this means that the new rendering state has not been visible on screen long enough to fully register with the user, so there's a legitimate case to be made that the prior rendering state is actually more relevant.

Benjamin Keen

Thanks for the context Stefan. That makes sense. Our main goal was to avoid consistently* running this expensive computation, and throwing away most of the work, when we only really care about the visibility just before the user switches tabs.

Since this is not idiomatic in blink, one last investigation I need to do is to check how frequently we run into the case that the document is not "clean" at the time the user switches tabs. It *may* be enough to just run the callback if the document is clean, and report not visible otherwise.

consistently*: When certain conditions are met (e.g. playing/audible video).

Benjamin Keen

After some local tests, depending on the site, the document can frequently be in a state other than "clean" when a user switches tabs. Therefore I've updated the CL to cache the visibility value as suggested by Stefan.

Frank, PTAL. Tx!

Open in Gerrit

Related details

Attention is currently required from:
  • Frank Liberato
Submit Requirements:
  • requirement satisfiedCode-Coverage
  • requirement is not satisfiedCode-Review
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. DiffyGerrit
Gerrit-MessageType: comment
Gerrit-Project: chromium/src
Gerrit-Branch: main
Gerrit-Change-Id: I3f3eb1e689a7d4a5e076de7026541682faaa269e
Gerrit-Change-Number: 5670552
Gerrit-PatchSet: 4
Gerrit-Owner: Benjamin Keen <bk...@google.com>
Gerrit-Reviewer: Benjamin Keen <bk...@google.com>
Gerrit-Reviewer: Frank Liberato <libe...@chromium.org>
Gerrit-CC: Stefan Zager <sza...@chromium.org>
Gerrit-CC: srirama chandra sekhar <srir...@samsung.com>
Gerrit-Attention: Frank Liberato <libe...@chromium.org>
Gerrit-Comment-Date: Thu, 25 Jul 2024 05:22:35 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: Stefan Zager <sza...@chromium.org>
Comment-In-Reply-To: Benjamin Keen <bk...@google.com>
satisfied_requirement
unsatisfied_requirement
open
diffy
Reply all
Reply to author
Forward
0 new messages