Skip to content
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

Screen Resolution Improvements #320

Closed
mmorrisontx opened this issue Jan 7, 2013 · 19 comments
Closed

Screen Resolution Improvements #320

mmorrisontx opened this issue Jan 7, 2013 · 19 comments
Assignees
Milestone

Comments

@mmorrisontx
Copy link

At the moment, it appears the only way to sniff screen resolution is via window.screen. Unfortunately, this only gives information about the display for the current window -- exposing nothing about systems with multiple displays.

At the moment, I have a (nasty) hack which moves a window around the sides of the screen to "test" if it lands on another screen or not. It's definitely not pretty.

It would be nice to have features to:

  • Get resolution and position of every display on the system
  • Trigger an event when the display layout changes in any way

I have a bit of experience with interfacing to this from c, but not enough to get anywhere near a pull request.

@mmorrisontx
Copy link
Author

It looks like this issue was touched on in #132 , but evolved into a separate problem.

@darsain
Copy link

darsain commented Jan 7, 2013

+1, definitely would use.

@trevorlinton
Copy link

Are you thinking an array that returns each screen the width/height, position relative, DPI? What do you mean by triggering an event when the display layout changes? E.g., when chromium needs to re-render a damaged surface? What's the use case for triggering a layout event?

@mmorrisontx
Copy link
Author

Yes, an array with screen width/height, position, and DPI would be ideal. Optimally, one of them would be identified as the primary screen in some way, but on most platforms this can be deduced by the screen with the top left at (0,0).

By "display layout changes," I mean the layout of the displays has changed. For example, the user has added or removed a monitor, or has changed the layout of their screen geometry (moved or rotated a display). This allows us to re-position anchored windows such as popups when the screen geometry changes.

The Qt framework has cross platform code for this event with its QApplication::desktop() "resized" signal, so I'll see if I can dig out how they did it.

@mmorrisontx
Copy link
Author

From what I can take from the Qt source,

On windows: The system sends your event loop a WM_DISPLAYCHANGE event, or a WM_SETTINGCHANGE event with a SPI_SETWORKAREA parameter.

On mac: The system sends your event loop a kEventClassApplication kEventAppAvailableWindowBoundsChanged message.

On linux: The system sends your event loop a PropertyNotify event, targeting the root window, for the _NET_WORKAREA property.

Unfortunately, that's pretty much the end of what my experience can do. I'm not sure if node-webkit even touches the event loop, but hopefully there's some way to intercept these events.

@mmorrisontx
Copy link
Author

Regarding notifications for desktop size changes: it appears chromium already has the majority of this code built in.

We can create a gfx::DisplayObserver and AddObserver it to the global gfx::screen object. The class provides three methods which will be called on screen configuration changes, OnDisplayBoundsChanged, OnDisplayAdded, and OnDisplayRemoved.

@trevorlinton
Copy link

I have a new build for transparency (with many bug/performance fixes) and screen resolution / display support almost ready. I'm finishing the testing on Mac OS X. I'll try to post a beta build today or tomorrow.

A few notes on transparency support:

  1. Support for both accelerated and non-accelerated painting is now supported.
  2. Compositing is no longer required for transparency support.
  3. I've made a graceful fall back if transparency isn't supported, adding IsTransparent property to Window
  4. Transparency unfortunately cannot have any other sibling controls, which means no file menu (in windows), no toolbar, no shadow and no frame. All max/min/resize/move events have to be handled via JavaScript (although all of them can be).
  5. Hit tests do not work on transparent regions. Unfortunately, this is quite a large problem (only in Windows), still looking for a solution.
  6. Added ability to see mousemove events outside of the window's client area.
  7. You can now get an array with the DPI, screen size, offset from origin (0,0) for each screen along with what screen the window's origin is in.
  8. Vista+ is only supported in windows, in addition if compositing is turned in DWM on windows transparency will fail.

More to come, hopefully this will wrap up to a stable transparency build.

@mmorrisontx
Copy link
Author

@trevorlinton I believe you're looking for #132

@trevorlinton
Copy link

Sorry @sonicsnes i'll post to both. This also includes detecting screen changes and getting screen layouts.

@mmorrisontx
Copy link
Author

@trevorlinton Ah! I'm looking forward to it ^_^.

@vibber
Copy link

vibber commented Jun 2, 2013

Hi there,
I am very interested in the feature that lets you get information on all active screens. But I'm a bit confused about the pregress for this. @trevorlinton where can I test the features you are describing? Did they manange to get included into the main branch yet?

@roeltz
Copy link

roeltz commented Oct 22, 2013

Is there any updates on this issue? I'm looking for ways to create a fullscreen muti-monitor app, but window.screen just gives information about the current display.

@trevorlinton
Copy link

@roeltz I work for a company that supports Node-Webkit commercially, we can add it to the roadmap. Shouldn't be difficult to add.

@acketon
Copy link

acketon commented Oct 30, 2013

I'd really love this for a multi-monitor kiosk system.

@trevorlinton
Copy link

trueinteractions#13 It's on track for 1.4 milestone.

@roeltz
Copy link

roeltz commented Oct 31, 2013

@trevorlinton Cool. Something along the lines of http://help.adobe.com/en_US/air/reference/html/flash/display/Screen.html, maybe?

@trevorlinton
Copy link

Added for Windows/MacOSX (for those building from source), I'll hopefully have binaries up tomorrow.

trueinteractions@f0086ca
trueinteractions@5cc3bf7
trueinteractions@f0086ca

@trevorlinton
Copy link

Screen support & transparency support are in the latest TInt binaries (See TIWindow.create/Devices.screens for more info). There's compatible node-webkit binaries in www.trueinteractions.com/trial.zip (Resources/Runtime.exe and Resources/Runtime.app). The source is up on our repo as well.

@rogerwang rogerwang self-assigned this Feb 28, 2014
@rogerwang rogerwang added this to the v0.9.3 milestone Feb 28, 2014
@jtg-gg
Copy link
Member

jtg-gg commented Aug 7, 2014

check out my pull request, on screen geometry API #2178

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants