if i have a fixed display layout that i want to spread across multiple monitors (say, a 2x2 grid of 1920x1200 LCDs), with each monitor containing a full screen-sized display, is it more efficient to create a single window that covers the entire output and make n display regions according to the placement of the displays, or is it better to create n Windows, each with a (0,1,0,1) DisplayRegion?
for instance, what’s the canonical Window/DisplayRegion arrangement for a cave?
i’m planning to do this via opengl on windows, but i’m flexible if another platform is a clearly superior choice for this type of arrangement, performance-wise.
It really depends on your graphics driver. You should probably try it both ways and see which is best for you. In fact, it would make sense to experiment with DirectX vs. OpenGL to see which is the better performer on your particular driver.
In my experience, though, typically one window that spans multiple displays is faster than multiple windows. Not universally, though.
multiple display regions is ahead so far because of some strange tearing-style artifacts in the top 1/3 to 1/4 of each auxiliary window. i’ve tried setting all the windows to the same sort, auxiliary windows progressively lower and progressively higher than the main window all with the same problem.
has anyone else experienced this sort of problem? again, this is using opengl in windows. i tried to change to the directx9 graphics pipe, but it failed, so i decided not to worry about cross-platform testing for now.
also, i noticed that the camera created via the Camera constructor does not have the same properties as the default camera (created using ShowBase.makeCamera()). if i were to use ShowBase.makeCamera() to create the cameras for these other regions, are there any gotchas i need to know about?
That tearing sounds new to me, but it sounds like as good a reason as any to stick to the one-window model.
As to the Camera, you should understand what base.makeCamera() does and how it differs from a simple Camera constructor. In particular, base.makeCamera() adds the camera to the base.camList, and parents it to base.camera, and does some additional setup such as creating a DisplayRegion and so on. You can read the code in ShowBase.py to learn exactly what it is that base.makeCamera() does.
But if by “Camera properties” you mean the lens properties, the easiest way to ensure your new Camera shares the lens properties with the original camera is to share the same lens: