Screen Resolution Improvements

[mmorrisontx]

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]

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

[darsain]

+1, definitely would use.

[trevorlinton]

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]

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]

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]

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]

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]

@trevorlinton I believe you're looking for #132

[trevorlinton]

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

[mmorrisontx]

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

[vibber]

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]

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]

@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]

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

[trevorlinton]

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

[roeltz]

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

[trevorlinton]

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

trueinteractions@f0086ca
trueinteractions@5cc3bf7
trueinteractions@f0086ca

[trevorlinton]

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.

[jtg-gg]

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