We recently purchased and installed a large LED wall in our company. Size of the total panel is roughly 7 x 3 meters. We can run the panel fine from a computer with one nVidia Titan card attached to it. Now, technically such a wall reports as two separate displays next to each other to the OS, like in the photo below:
Using nVidia Surround technology it is possible to run the same panels as if it was one single large monitor, on a resolution of 5760 x 2160. So far so good.
What doesn’t work is the maximize button of Blender. Even though nVidia Surround is active and correctly configured (and works with apps like PowerPoint), Blender always maximizes to only half of the wall. It is of course possible to drag the window out and stretch it, but it is NOT possible to use fullscreen mode properly, which would be superb for client presentations.
So the real question is: Is the maximize button on such a config supposed to work? Are we missing something on our side? Or is there something that can be done in the Blender source code?
I wasn’t sure if this is better suited in the UI category or in the Blender Development one, feel free to move it wherever it belongs.
Update: We tried using all of the command line switches, --window-fullscreen, --window-geometry 0 0 5760 2160, --window-maximized, isolated and / or in different combinations with each other. Seems to me that internally the window geometry size is being clipped to the prinary screen width and height, because we always see the window on the left half.
We have the Windows OS itself place and size our windows within the confines of your monitors. If your desktop looks like the image you posted earlier in this thread, then Windows considers you to have two monitors, side-by-side, not a single one of combined resolution.
That’s because our IT took the picture when surround was not configured yet. Still, even with surround turned on, the maximize button is “not working”, aka showing the same behavior as if it was a dual monitor setup.
I wonder though why the --window-geometry switch alone would not stretch the Blender window across the dual monitor setup. Browsing the source code, Blender does not seem to clamp the window size to the size of the monitor anywhere, it just clamps the minimum to be at least 640 x 480 in WM_init_state_size_set() as far as I can tell.
Would make sense to add another one after it showing what the desktop looks like with that configured.
the maximize button is “not working”, aka showing the same behavior as if it was a dual monitor setup.
I’d really have to know what the OS thinks of your configuration, ie how many monitors and the resolution of each.
Browsing the source code, Blender does not seem to clamp the window size…
If you look at the Win32 window creation code in …\blender\intern\ghost\intern\GHOST_WindowWin32.cpp you will see a function called adjustWindowRectForClosestMonitor that adjusts the requested dimensions to fit within the confines of the nearest monitor. Using the Windows API call AdjustWindowRectExForDpi if on Windows 10, AdjustWindowRectEx otherwise.
Thanks Harley,
I’ve asked IT to provide photos and infos of that surround configuration. Due to complexity in our Powerwall setup, this means physically disconnecting a row of Panels (to have both screens at the same resolution), only then Surround can even be activated. They promised to do this within the next few days when no one uses the wall.
Your tip with the function in Win32.cpp however got us a long way already. I simply disabled the clamping calculations, leaving the rest of the code intact, and this already allows us to use the --window-geometry switch as intended. Now the window opens and spans across the whole wall, even though Surround is not activated. For client presentations this is currently sufficient!
Code looks like this:
/* Constrain requested size and position to fit within this monitor. */
/*
LONG width = min(monitor.rcWork.right - monitor.rcWork.left, win_rect->right - win_rect->left);
LONG height = min(monitor.rcWork.bottom - monitor.rcWork.top, win_rect->bottom - win_rect->top);
win_rect->left = min(max(monitor.rcWork.left, win_rect->left), monitor.rcWork.right - width);
win_rect->right = win_rect->left + width;
win_rect->top = min(max(monitor.rcWork.top, win_rect->top), monitor.rcWork.bottom - height);
win_rect->bottom = win_rect->top + height;
*/
Yes, if you can find a way to add the functionality you want while keeping existing safeguards, consider submitting a patch.
The current behavior of constraining newly-created windows to the nearest monitor is to ensure that windows are visible when a blend file is sent to a user with a different arrangement of monitors. Without this the OS is perfectly fine with creating a window outside your visible desktop area. Creating an invisible window is a complication we’d rather not have to deal with on the bug tracker.
But perhaps this check could be skipped if size and position are set directly from command-line.
