+1
That would be nice :)

Graphics cards tend to have much more than two display outputs nowadays, and we kind of prefer Fullscreen to External (less delay, no need for extra video out cards). So for us Fullscreen is better, if which type of Output is a question.

Working with another client that needs 5+ outputs.

I think there is a legitimate need here.

- Tom

Do you really need 5 or 6 different outputs?

Ahh, sniffer was picking up controls from the system.windows.controls namespace.
I hardly see any CPU bump when going from program window to enabling the 2 fullscreen outputs (actually I see none), not sure what the leap is to 4+ as I cannot test but I would assume it to be linear in proportion. This is why I think a non arbitrary cap would be nice, those of us with more powerful systems should not be gated because of other systems.

Direct 3D rendering can be tricky, as someone who primarily develops games these days I know from experience, not sure what library you are using or if its a homebrew, but some absolutely are better than others as D3D relies heavily on the interfacing library to handle resources and threading. Perhaps a glance at OpenGL is worthwhile as when applications are coded explicitly with OpenGL in mind they have been proven to be many times faster than D3D.

Skipping the direct frame writing and outputting of frames to device and looking at an alternative using custom D3D (or existing ones) controls in a WPF wrapper is also worth considering as WPF already leverages GPU for rendering and FPC's related to such. Also would make threading much easier.

An amendment to my previous comment, I realize that you said you use D3D and I mistakenly checked my CPU during enabling and disabling full screen and I just checked again but while keeping an eye on my GPU stats and discovered something curious/disturbing.

As i'm sure you are aware most GPUs have a variable clock, It would appear that either the library you are using for your D3D is overriding the GPUs clock (not unheard of, applications like Adobe lock the clock to ensure max performance) or the clock is being miscalculated based on the programs use and SHOULD be locked.

My PCs GPU idles at around 325mhz, When I launch vMix and add a few videos and inputs my GPU rightfully locks at 3gHz keeping my load nice and low so video is smooth (4 cameras put me at 3-4% load) However, and here's the problem, and part of the reason why you are seeing bad benchmark data when writing for fullscreen outputs; When I enable full screen, my clock then drops back to 324mhz causing the GPU Load to increase (now somewhere in the range of 33% for the same 4 cameras)! I can manually lock my GPU clock back to 3gHz using a GPU utility I have and my load drops back down to 3%-4% load with both full screen outputs on.

So something is definitely amiss.

Wouldn't necessarily need 6 computers, but NDI certainly opens a lot of possibilities, I just received my NDI SDK this morning (they have been experiencing server issues) and the NDI protocol and framework is extremely well written and imposes very little overhead, I see this protocol opening up a lot of output capabilities and intend to write some of my own software to fill some issues I had with limited outputs as well. I just can't wait to get my hands on vmix 17 to fully test its capabilities.

Also, with regards to NDI, the same limitations apply, it doesn't improve the performance of the PC, just allows connectivity over
the network instead of HDMI or SDI.

So it is not going to be able to expand the number of unique outputs because the same GPU limits apply. Also there is a small amount of CPU usage
needed for each NDI session, so keep that in mind.

Regards,

Martin
vMix