Open SamB opened 3 years ago
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.
@jernoble Is it the same in Safari?
Is this an implementation issue or shall the spec be updated? What are your thoughts?
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.