[Webkit-unassigned] [Bug 232125] New: Refactor handling of HTMLMediaElement::mediaPlayerRenderingCanBeAccelerated

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=232125

            Bug ID: 232125
           Summary: Refactor handling of
                    HTMLMediaElement::mediaPlayerRenderingCanBeAccelerated
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jean-yves.avenard at apple.com

Related to bug 232124

There are three conditions that needs to be controlled:
1- Can the media player be accelerated
2- Can the renderer be accelerated
3- Should the video playing in this renderer be accelerated.

Right now, the logic is about as follow:

- The MediaPlayerPrivate contains the information related to 1.
- When the MediaPlayerPrivate needs to know 3) for the purpose of handling the call to acceleratedRenderingStateChanged, it will query the MediaPlayer, which queries the HTMLMediaElement client for 2), for this it will query the RenderLayerCompositor which will return false if accelerated rendering is disabled and if not queries the RenderVideo, which itself queries the HTMLMediaElement which queries the MediaElement which queries the MediaElementPrivate to determine if the player itself can be accelerated.

And there are some exceptions to the above if we are in PiP or in fullscreen then we assume it's always accelerated.

Not getting the information about the video being played in an accelerated layer right, causes the media to play without video and just audio. There's been multiple bugs related to the information not being correct when checked:
(bug 230495, bug 215594, bug 220375 to name a few)

We should split things so that the MediaPlayerPrivate only knows about 1; the compositor only knows about 2. And it's up to the HTMLMediaElement to determine 3 and relay this information to the MediaPlayerPrivate.

So there's no race or conflicting information between the various parties.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211022/0896777b/attachment-0001.htm>