On 4/24/2018 11:53 PM, Sergey Bylokhov wrote:
On 24/04/2018 13:22, Anton Tarasov wrote:
Clarification. The coordinate should not actually be split into
displays every time it's scaled up/down. It's enough to calculate its
offset in the "terminal" display and scale it accordingly. Then have
all the displays already mapped b/w device and user spaces. But the
problem is right here. Even in the current implementation, when there
are two displays with different scales, their bounds are converted to
the user space incorrectly. The conversion is straight-forward -
scaleDown(x,y), ScaleDown(w/h). However, in order to keep the layout
of the displays in the user space, the origin of a display should be
scaled by the scale factor of the adjacent display, not its own.
I remember that we tried to implement it this way, or even implemented
it this way, but changed later. The problem in situation above is
occurred if there are a few screens on the left side with different
scales and it is unclear which one should be used to scale the x,y of
the right screen. Situation became worse if there are some holes
between screens, or screens are intersected.
Well, in theory I'm thinking of the following. Consider introducing a
notion of a coordinate with a state: unresolved, resolved. An unresolved
coordinate can be resolved only in relationship. Say, an origin of a
monitor adjacent to several other monitors with different scales
(ambiguous situation mentioned above) is resolved to a fixed value (in
user space) in relationship to a particular adjacent monitor. The
relationship comes into play when, roughly speaking, you need to
calculate a distance b/w two points, belonging to two different
monitors. In case of the origin of a monitor, the other point would be
the origin of another monitor.
Hard to say if it's feasible (and relevant) in the context of Swing/AWT...
Regards,
Anton.
