<Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows
Anton Tarasov
anton.tarasov at jetbrains.com
Wed Apr 25 10:46:27 UTC 2018
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.
More information about the swing-dev
mailing list