tracker_attached_to_document_->GetFrame()->View()->UpdateAllLifecyclePhases(
Benjamin KeenThis 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?
Stefan ZagerIIUC, 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?
Benjamin KeenIf the tab containing the video is backgrounded, why can't you just unconditionally report the video "not visible" and be done with it?
Stefan ZagerHmmm, 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?
Benjamin KeenIf the document is backgrounded, then the video element is by definition not visible. Am *I* missing something?
Stefan ZagerTo 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.
Benjamin KeenJust 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 KeenThanks 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).
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!
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. | Gerrit |