On 4/24/2018 9:07 PM, Anton Tarasov wrote:
However, there's some serious problem in this construct which you may
have noticed. It's here:
x = peer->ScaleDownX(rect.left);
'rect.left' may span a number of displays, each with different scale.
Thus, to get the real ScaleDown, rect.left should be split into parts,
corresponding to the displays it crosses.
Then a display scale should be applied to each part, and then the sum
would be the correct result in the user space. As for now, the result
is incorrect.
Why it works is just because textInWindow.getLocationOnScreen() is
immediately passed back to native, where it is up-scaled the same
(incorrect) way.
However, in other cases this problem may cause issues. And I have no
simple solution for it...
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. It's not a problem for two
displays, however it's a problem for three (or more). Imagine you have
three displays with different scales, two are placed in a row and the
third is placed underneath b/w the two (by the x-axis). Now, you can
scale the origin of the third display by the scale of the first or the
second. In either case, the layout in user space will be broken. And if
you try to calculate a distance b/w two UI elements, which crosses the
displays, it may be incorrect when converted to the device space.
Regards,
Anton.
