-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Fullscreen support on multiple screens #92
Comments
I've updated the title for clarity. Anyone is welcome to share use cases for such a request. This is a complex subject, because it's unclear how the Fullscreen API, in particular Element.requestFullscreen() would map a single element to an arbitrary region corresponding to multiple displays. The only way to accomplish anything like this, currently, is to open multiple windows and make each one fullscreen on a separate display. Unfortunately, that requires ~1-2 user gestures for each screen. I think this request would be best served by a new Fullscreen API entrypoint. The first step to making that a reality is demonstrating a need for the web platform to support this functionality. |
I am working for a large PACS vendor. PACS viewers are used by radiologist to review and provide diagnostic based on medical imaging. I imagine you are familiar since it's the 3rd motivating example on the draft spec. It's not uncommon for radiologist to have "cockpits" with 5 monitors. At the same time, Radiologist are notoriously averse to any unnecessary interactions or "clicks". We currently use an electron wrapper to enable seamless multimonitor and app-like behavior. I am currently experimenting with desktop pwa, window-overlay and multi-window placement to retire electron, but it currently falls short. We definitely need to way to either 1) make different divs of a single page full screen or 2) be able to position a window across multiple monitors (maybe at least in PWA?) and/or 3) to be able to launch multiple window without with noopener in full screen. about no3 and noopener, this might be needed because opening 4 heavy fullscreen windows all sharing the same process/main js thread makes it really hard to keep performance up. As of now, we have reduced the electron footprint to a minimum by using window-placement for no2, but I still have to make browserWindow.setPosition/setSize from the node side available on the web side to avoid the clamping applied to window.moveTo and window.resizeTo. BTW, it's really annoying that moveTo(0,0) leaves a ~10x gap on windows.. I also would like this to go over the taskbar. I understand that some of these are security consideration, but maybe it could be handled via a permanent/remembered permission, or maybe relaxed for installed PWA? As it is today, it covers 95% of was is needed for medical applications, but the remaining 5% is really just disqualifying.. |
At present, more and more web applications have a resolution of 3840*1080, or even larger. Chrome's Fullscreen Mode (press key F11) only supports a single monitor, which cannot display all the content of the web application, so we urgently need Consider expandable FullscreenMode (perhaps pressing alt+f11 ) to support fullscreen capability on multiple monitors |
Another data point. I just spoke with an integration specialist for our existing medical viewer and I am told mixed resolution workstation are common where for example one diagnostic monitor would be 3 megapixels and the the other 5. This would make the stretched approach unusable. An alternative would be 1)the multiple Also, going with 2) it would be nice to be able to do that without opener reference. It's really hard to have the worklist plus 2 or 3 full diagnostic viewer window perform well when all sharing the same process and main thread. |
No description provided.
The text was updated successfully, but these errors were encountered: