Upgrade path from NVIDIA NVS 810 to drive 8 monitors?
- Thread starter goslow
- Start date
This is an open invitation to gremlins. Odds of this setup working hassle free, including monitors going to sleep and waking up as they should, and without spontaneously rearranging your windows, are approximately ZERO.
Also don't mix and match GPU brands or GPU lines (e.g., Quadro/RTX and GeForce). Best to use matching GPUs if need two.
But OP, if your eyes can handle it, you might consider 27" 2k monitors - 1 of those at native resolution is going to give you the same screen real estate (almost, since yours are 1920x1200 rather than 1920x1080) as 2 of your current monitors. I'd suggest going to MicroCenter and seeing what resolution/screen size combos your eyes can comfortably handle at normal desk distance. 4 monitors is going to create less neck strain than 8 monitors.
Agree all around.... same GPUs if >1... same model monitors if possible. Want to make things "easy as possible" for Windows Extended Desktop function.
I have 4x, 27", 4k monitors (3 of them for charts in portrait mode)... all the same model... and I don't put them to sleep... reboot each day.
Windows can set the font size in 4k so that text is the same as 1920x1080 but with the added res to display more bars on a chart. I also have 4k res on laptop and it is OK for text nearly always... though a few exceptions with text tiny in some apps.
OP has NVS 810 video card. Should run 8x, 4k monitors according to specs. The 810 is "top of the line for NVS", so likely it's quite good.
Last edited:
Scataphagos and others:
Here's a sample MultiCharts app window with child windows tiled on a 2row-x-9col grid.
The sample is useful on a 1-x-3 or 2-x-3 monitor array, as charts need not cross monitor edges. Other samples have gone as high as 4row-x-12col. Limits include quotas on Windows GDI and User handles, and graphics card strength.
This should work with charting programs other than MultiCharts. The key is that there be an accessible serialization (workspace) file.
I have other tools directed at automating operations on groups of workspace files...e.g., creating them on demand, changing them programmatically.
Msg if interested to hear more.
Why is this software necessary? Meaning, do you actually move your charts (such as the multichart window in the link) from monitor to monitor?Scataphagos and others:
Here's a sample MultiCharts app window with child windows tiled on a 2row-x-9col grid.
The sample is useful on a 1-x-3 or 2-x-3 monitor array, as charts need not cross monitor edges. Other samples have gone as high as 4row-x-12col. Limits include quotas on Windows GDI and User handles, and graphics card strength.
This should work with charting programs other than MultiCharts. The key is that there be an accessible serialization (workspace) file.
I have other tools directed at automating operations on groups of workspace files...e.g., creating them on demand, changing them programmatically.
Msg if interested to hear more.
On a related note, I use MS PowerToys FancyZones to create layouts for each monitor and then snap windows to whatever zone I want. One annoyance is that trading platform windows often don't recognize 'zones' created by FancyZones or similar software such as DisplayFusion. I've seen this with IB Trader Workstation, thinkorswim, Quantower. I have to manually size these windows to fit a zone. Fortunately they retain their size on restart. But it would be nice if they would 'snap' to zones similar to how most app windows behave. Sounds like something you are familiar with?
Scataphagos and others:
Here's a sample MultiCharts app window with child windows tiled on a 2row-x-9col grid.
The sample is useful on a 1-x-3 or 2-x-3 monitor array, as charts need not cross monitor edges. Other samples have gone as high as 4row-x-12col. Limits include quotas on Windows GDI and User handles, and graphics card strength.
This should work with charting programs other than MultiCharts. The key is that there be an accessible serialization (workspace) file.
I have other tools directed at automating operations on groups of workspace files...e.g., creating them on demand, changing them programmatically.
Msg if interested to hear more.
many windows on the same instrument is meaningless, one must be the primary and other would be the confirmations. i use mc too but not in this way.
Vic38, Thanks for the input and for pointing me to FancyZones and DisplayFusion. I'll start looking at those.
Re moving arbitrary programs into zones with low effort...
Snapping programs to zones is pretty easy. One needs a little program like "Mover" to find a running app by its name (e.g., TWS) and move it to a zone given its name.
The logic can also be embedded in a workspace post-processor program that writes the zone coords into the workspace file before it is run.
I define zones by location in a 2x4 array of equal-sized monitors. "_Mons17_" has monitor #1 in the UL corner and #7 in the LR corner. Actual coords are in pixels relative to the UL corner of the primary monitor. You can calculate them, or look them up with Spy++ in Visual Studio. I have a switch statement that maps strings like "_Mons17_" into zone rectangle edges (top, right, left, bottom). The _Mon syntax has some ad-hoc extensions to define partial monitor width and height, and also off-desktop monitors (e.g., imaginary nonexistent mon #0 to the left of mon #1, so windows can be moved partly off-screen). That syntax could be made more general and extended.
You invoke Mover by double-clicking a desktop shortcut to a batch file that gives Mover an app name, and a zone name. Mover then finds coords of the zone name, finds the app process, and moves the app main window to the coords.
The logic can also be embedded in a workspace post-processor program that writes the zone coords into the workspace file before it is run.
I define zones by location in a 2x4 array of equal-sized monitors. "_Mons17_" has monitor #1 in the UL corner and #7 in the LR corner. Actual coords are in pixels relative to the UL corner of the primary monitor. You can calculate them, or look them up with Spy++ in Visual Studio. I have a switch statement that maps strings like "_Mons17_" into zone rectangle edges (top, right, left, bottom). The _Mon syntax has some ad-hoc extensions to define partial monitor width and height, and also off-desktop monitors (e.g., imaginary nonexistent mon #0 to the left of mon #1, so windows can be moved partly off-screen). That syntax could be made more general and extended.
You invoke Mover by double-clicking a desktop shortcut to a batch file that gives Mover an app name, and a zone name. Mover then finds coords of the zone name, finds the app process, and moves the app main window to the coords.
Why is the software necessary?
It's part of a bigger effort to generate or modify MultiCharts workspaces programmatically. Applications themselves can be snapped to zones, as described. But within the app itself, charts can be snapped to app-relative grid locations not related to zones, but typically contained within a zone. (That 18-chart grid could live in a zone of 3 or 6 mons.)
Also, the bigger set of tools make global (workspace-wide) changes to things like inter-bar spacing, candles versus bars, colors, status bar settings, study settings, study margins. Also I have tools related to price-vol statistics and to inter-app-instance messaging that have nothing to do with window positioning.
By scripting this stuff, it means workspaces will have a standard but changeable appearance, and can be restored quickly by running a post-processor script on the workspace.
By scripting this stuff, it means workspaces will have a standard but changeable appearance, and can be restored quickly by running a post-processor script on the workspace.
Do I move charts around?
Not often. I define workspaces for a known zone, but use a Mover-like program to put them in a different zone or move them back. Popping out and maximizing individual windows are always possible as temporary, not-to-be-saved changes.
Something similar to what you're using now would support mouse-clicking on a chart, then mouse clicking on some zone definition (maybe a shell link, maybe just a screen location or a picture of the desktop), and execute a move-to-zone action.
Thanks for the chance to talk about this. A next step would be to think about how best to export desktop layout in a machine-independent form as a list of available monitors and relative positions.