I'd like V UI to support the following case (which is very common and won't disappear because of huge overlap of lifetimes of screens). Native GUI libs usually don't support it at all, but let's hope there are some workarounds.
Let's assume I have 3 different physical LCD displays and want to use a V UI application on all of them simultaneously (one application window spanning across all three displays). The LCDs are physically placed like this:
(note the bezels which make the physical displaying surface non-continuous)
This is how the physical surface itself looks like:
Graphic cards nowadays support more displays using a "virtual" huge "multibuffer canvas" where all the 3 different "framebuffers", each corresponding to one and only one LCD, must fit in. But because each LCD has not only different physical dimensions, they have also different resolutions and therefore the "multibuffer canvas" (yellow color) used by graphic cards to draw the actual pixels to looks like this:
The issue is, that all UIs known to me do not have the capability to support different resolutions in different areas of the "multibuffer canvas" and thus they just choose some "random" DPI (usually the DPI of the first physical display in the list of physical displays connected to the running system, which is of course unpredictable) with the following result:
Which looks on the whole physical surface like this:
(copy of https://gist.github.com/vurtun/61b6dbf21ef060bcbbd8d1faa88350d9#gistcomment-2223201 )
Path to full DPI and screen size independency
I'd like V UI to support the following case (which is very common and won't disappear because of huge overlap of lifetimes of screens). Native GUI libs usually don't support it at all, but let's hope there are some workarounds.
Let's assume I have 3 different physical LCD displays and want to use a V UI application on all of them simultaneously (one application window spanning across all three displays). The LCDs are physically placed like this:
(note the bezels which make the physical displaying surface non-continuous)
This is how the physical surface itself looks like:
Graphic cards nowadays support more displays using a "virtual" huge "multibuffer canvas" where all the 3 different "framebuffers", each corresponding to one and only one LCD, must fit in. But because each LCD has not only different physical dimensions, they have also different resolutions and therefore the "multibuffer canvas" (yellow color) used by graphic cards to draw the actual pixels to looks like this:
The issue is, that all UIs known to me do not have the capability to support different resolutions in different areas of the "multibuffer canvas" and thus they just choose some "random" DPI (usually the DPI of the first physical display in the list of physical displays connected to the running system, which is of course unpredictable) with the following result:
Which looks on the whole physical surface like this: