You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
functiononPipWindowResize(event){// Picture-in-Picture window has been resized.const{ width, height }=event.target;updateVideoSize(width,height);}functionupdateVideoSize(width,height){// TODO: Update video size based on pip window width and height.}
The problem I'm seeing here is that the width and height attributes on the PictureInPictureWindow are defined to be in units of CSS pixels, but in order to do what we want, updateVideoSize would need width and height in device pixels, and I can't personally see any reason to assume that the Picture-in-Picture window will be using the same pixel density as the main browser window, so window.devicePixelRatio doesn't necessarily tell us what we want to know.
(Naturally, the actual algorithm to choose from among the available streams would be beyond the scope of this example, and the mechanism to switch streams is right out, but presumably those would have been implemented for non-PiP mode first anyway.)
Possible approaches:
Add a devicePixelRatio to PictureInPictureWindow. (This would obviously require sites be updated to take advantage of it, including some conditional math.)
Decide that width and height aren't actually in CSS pixels after all. (What do browsers actually do here, anyway?)
Decree that the PiP window match window.devicePixelRatio. (This might do ... funny things if the user zooms in or out.)
Add new deviceWidth/deviceHeight attributes (modulo bikeshedding) that use device pixels. (This would require updates and a conditional again, but most likely || instead of the math.)
Basically, I would find out what browsers actually do here, and if they're actually reporting device pixels already I'd go with 2, and otherwise I guess I'd lean towards 4.
The text was updated successfully, but these errors were encountered:
On single monitors, window.devicePixelRatio is enough to determine the proper video size in the PictureInPictureWindow. However you're right, it doesn't necessarily work if multi screen environments.
In Chromium, the resize PictureInPictureWindow event is not even fired when users moves PictureInPictureWindow from one screen to another one.
The "Update video size based on Picture-in-Picture window size changes" seems to skip over a key aspect of updating the video size:
The problem I'm seeing here is that the
width
andheight
attributes on thePictureInPictureWindow
are defined to be in units of CSS pixels, but in order to do what we want, updateVideoSize would need width and height in device pixels, and I can't personally see any reason to assume that the Picture-in-Picture window will be using the same pixel density as the main browser window, so window.devicePixelRatio doesn't necessarily tell us what we want to know.(Naturally, the actual algorithm to choose from among the available streams would be beyond the scope of this example, and the mechanism to switch streams is right out, but presumably those would have been implemented for non-PiP mode first anyway.)
Possible approaches:
devicePixelRatio
toPictureInPictureWindow
. (This would obviously require sites be updated to take advantage of it, including some conditional math.)width
andheight
aren't actually in CSS pixels after all. (What do browsers actually do here, anyway?)window.devicePixelRatio
. (This might do ... funny things if the user zooms in or out.)deviceWidth
/deviceHeight
attributes (modulo bikeshedding) that use device pixels. (This would require updates and a conditional again, but most likely||
instead of the math.)Basically, I would find out what browsers actually do here, and if they're actually reporting device pixels already I'd go with 2, and otherwise I guess I'd lean towards 4.
The text was updated successfully, but these errors were encountered: