[Bug 16502] Define multiple monitor support and per-subdomain

https://www.w3.org/Bugs/Public/show_bug.cgi?id=16502

fbender <fb+w3c@quantumedia.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fb+w3c@quantumedia.de
                 OS|Windows 3.1                 |All

--- Comment #5 from fbender <fb+w3c@quantumedia.de> ---
I think there are several use cases where multi-monitor support for web apps is
desirable. The following use cases require one or more fullscreen views on
separate monitors, either due to presentational reasons or UI focus /
maximizing available screen real estate. 


1) A presentation system: Slides on one screen (e. g. DVI-attached projector),
controls/notes/time etc. on another (presenter-facing) monitor (e. g. internal
notebook monitor). See e. g. Keynote's multi-monitor mode. Any chrome is
distracting in this case. 

2) Streaming video from a web app (e. g. on a phone/tablet) to a TV (secondary
screen) while displaying a remote on the primary internal screen. Compare with
e. g. YouTube app with AirPlay. 

3) Many professional or industrial applications can benefit from a
multi-monitor setup to extend the number of things you can display at once,
have multiple concurrent views with different characteristics (e. g. a data
view on one monitor and controls on a touch screen), or have multi-user setups
(e. g. a controller, a supervisor and a visitor view, see also #1). Chromeless
windows are not required, however having a fullscreen view will clearly benefit
the app's UX. 

4) A multi-monitor broadcasting system (with network-attached screens), e. g.
company- or department-wide announcement screens. It may sound strange, but I'm
sure there are applications where this is very useful. This may also work for
TV studio setups though the web is certainly not the right platform to use here
(at least yet). 


I cannot think of non-fullscreen use cases, those can actually be accomplished
with popups (but probably not mixed fullscreen and popups, at least with
current implementations). Thus extending the current requestFullscreen API
would be a straightforward approach to solve that problem (IMO). 

So this is just a rough sketch (certainly not a syntax proposal) but it could
work like that (somehow related to use case #4): 

```
navigator.getAvailableVideoStreams(function(streams){
  let destinations = [];
  for dest of streams {
    if (dest.isRemote) 
      destinations.push(dest);
  }
  videoElement.requestFullscreen({destination: destinations});
});
```

The available video output streams (each stream is an independently accessible
video out stream, as defined by h/w and OS) may indicate if they are local (e.
g. attached via DVI) or remote (e. g. via network). The streams should indicate
their native resolution (`dest.resolution = [width,height,depth?]`). 

The streams may also provide interfaces for ambient light, brightness,
integrated speakers etc., but their use cases are rather academic and certainly
out of scope for a v1 (plus, no hardware may support any of this; I'm just
exploring possibilites). 


Either way, I think this is a useful and much needed addition to current
functionality. This may also be an important feature for B2G-like
phones/tablets for tethered or wireless video/interface output (where the
current requestFullscreen itself does not make immediate sense). Additionally,
having a totally different API for this feature does not seem to be a practical
approach here (IMO).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 2 April 2013 20:05:02 UTC