<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