If you have multiple MultiTactions and multiple graphics card, the configuration gets somewhat complicated. To master this, think of the problem as consisting of two logical phases, i.e, first you need to define a window and then one or more areas inside that window. To understand the reason for areas, look at the example figure below with two graphics cards G1, G2 and three MultiTactions in portrait layout. The G1 has two outputs that are connected to the two leftmost MultiTactions. Even if the MultiTactions are next to each other with no air gap between them, there is a gap corresponding to about 60 pixels between them due to the physical bezel of the MultiTactions. The G1 doesn't know about this and if we simply draw a line across the MultiTactions, the line is offset producing unnatural look. Areas are used to define another set of coordinates to overcome the offset problem for Cornerstone based applications. Points D(1080,0) and E(0,0) denote locations as seen by the two graphics cards, which don't know about the gaps.
outside the MultiTactions are in application coordinates."
Usually you want application windows to span the whole visible surface in MultiTactions, but for illustration purposes let's define windows as shown on the right hand figure above. The highlighted region spanning three MultiTactions is what an application programmer sees, i.e., a drawable region with origin at F'(0,0) and width and height being 3144 and 1387 pixels, respectively. The programmer does not have to worry about the non visible regions between the MultiTactions, graphics drawn there simply appear to be hidden under the bezels.
An efficient way to use graphics resources is to define one window per one physical graphics card. In the example G1 produces the window 1 spanning two MultiTactions and the window 2 is produced by G2. The configuration proceeds as follows
screen and windows are located relative to it. Assuming the screen 0 spans the first two MultiTactions and the screen 1 covers the rightmost MultiTaction, the J has location J(0,213), i.e., it's relative to the screen 1 origin.Here is the same in XML (windows only). In the example it was also assumed that the application drawing area "pixels" matched the physical pixels, i.e., not scaling or distortion in the application coordinates.