Re: Extend fullscreen API to support second screen

ÓÚ 2014/8/28 22:23, Rottsches, Dominik дµÀ:
> Hi Duan,
>
>> What did the "hooking it into Fullscreen API" approach look like in your
>> mind? and what requirements and use cases it couldn't match?
> The requestFullscreen() function does not allow a screen choice for example. Also, just the naming does not match what we want to do. requestFullscreen() is a feature of a DOMElement. There are additional issues with ¡°ripping out¡± a DOM element out of the one page, and placing it onto a remote screen. This would not work well in a two-UA implementation situation. So, starting with a new API seems like the better approach.
In previous discussions with Francois, I suggested a new method
Element.requestSecondScreen(), which is similar to requestFullscreen()
but for the second screen. For 2-UA case, I suggested that let local UA
render the fullscreened element at the size of the remote display, and
stream the live video to remote UA. What do you think?
>> Do you think we still want a Fullscreen API like, partial mirroring API,
>> accompanied with the current Presentation API? App-level mirroring seems
>> still hard with current Presentation API, and some demos require
>> browsers' private APIs.
> If your content is downloaded from a web server, I think ¡°partial mirroring¡±, or showing the same content on two screens, nicely adapted to each screen's size and display resolution is not hard with Presentation API at it¡¯s current incarnation. So personally I don¡¯t think mirroring support in the API is a high priority.
As discussed previusly, it is not always esay to keep the two page in
sync. E.g. animations/games using random numbers; 2-UA have different
input devices and some of them may be hard to simulate by JS, etc.

Also, with requestSecondScreen(), authors program in a single page,
which is much simpler than cross-page communications.

Duan Yao.

Received on Thursday, 28 August 2014 15:26:08 UTC