<Swing Dev> [11] RFR JDK-8189687:Swing: Invalid position of candidate pop-up of InputMethod in Hi-DPI on Windows

Sat Mar 31 01:21:18 UTC 2018

I guess we need to check it again.
We have two coordinate spaces in awt/swing:
  - User-space which is used by all(most) of our API in awt/swing. It 
means that all methods like setSize/setBounds/getLocationOnScreen etc 
use this coordinate space.
  - Device-space which is used by the native system. It is used when we 
show something on the screen, when we get some notification from the OS etc.

So for the example if we try to set the bounds of the window then we 
convert the size from the user-space to device-space. But when we get 
some notification from the native system then we will convert 
device-space to the user-space.

In this bug we use wrong location of candidate window. It means that we 
lost some conversion.

So if we start from the first iteration of the fix:
http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java.sdiff.html

We calculate the x,y in two places using getTextLocation() and 
getLocationOnScreen(). Both functions should return coordinates in the 
user-space because both are public API in AWT. If some of these methods 
use wrong device space it should be updated(in the place where we get 
such coordinates from the native).

We show the candidate window using openCandidateWindow() method, this 
method uses x,y coordinates. In which coordinate system x,y should be?
If it uses device space then we should convert both - results of 
getTextLocation() and getLocationOnScreen().

On 28/03/2018 22:02, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> The code flows to JTextComponent.getTextLocation() which does not return 
> a scaled rectangle as it uses awt_Component.cpp#_GetLocationOnScreen 
> where it is scaled down. Do you want me to move the code to 
> JTextComponent.getTextLocation() instead?
> 
> Regards
> Prasanta
> On 3/28/2018 9:06 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> The same question about this code:
>> 281         Rectangle r = getReq().getTextLocation(offset);
>>
>> The getReq() returns InputMethodRequests which is implemented by a 
>> number of classes, and I think one of them 
>> "InputMethodRequestsHandler" returns scaled values from 
>> "getTextLocation()" already.
>> Some of these classes may return some stubs which should not be 
>> scaled, like in CompositionAreaHandler:
>> // passive client, no composed text, so fake a rectangle
>> return new Rectangle(0, 0, 0, 10);
>>
> 
>>
>> On 27/03/2018 22:39, Prasanta Sadhukhan wrote:
>>> Any more comments?
>>>
>>> Regards
>>> Prasanta
>>> On 3/26/2018 1:21 PM, Prasanta Sadhukhan wrote:
>>>> Hi Sergey,
>>>>
>>>> On 3/23/2018 3:44 AM, Sergey Bylokhov wrote:
>>>>> Hi, Prasanta.
>>>>> Did you check why the "InputMethodContext.getTextLocation()" 
>>>>> returns non-scaled rectangle? Maybe we should do this inside 
>>>>> InputMethodContext()?
>>>>>
>>>> Yes, this code 
>>>> http://hg.openjdk.java.net/jdk/client/annotate/f46bfa7a2956/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp#l5673 
>>>>
>>>> scales down x,y as part of JDK-8073320 fix.
>>>> I have moved the fix to InputMethodContext as suggested
>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.02/
>>>>
>>>> Regards
>>>> Prasanta
>>>>> On 20/03/2018 22:17, Prasanta Sadhukhan wrote:
>>>>>> Hi Krishna,
>>>>>>
>>>>>> Yes, I did not provide any since the testcase needs to be manual 
>>>>>> and would have to contain lots of instructions of how to install 
>>>>>> Japanese language and changing the input mode to hiragana
>>>>>> and also similar fix of input method earlier did not have a 
>>>>>> testcase for similar reason.
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>> On 3/20/2018 8:42 PM, Krishna Addepalli wrote:
>>>>>>>
>>>>>>> Hi Prasanta,
>>>>>>>
>>>>>>> Now the changes look fine. However, I noticed that there is no 
>>>>>>> testcase associated with this fix. Is that intentional?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Krishna
>>>>>>>
>>>>>>> *From:*Prasanta Sadhukhan
>>>>>>> *Sent:* Tuesday, March 20, 2018 5:04 PM
>>>>>>> *To:* Krishna Addepalli <krishna.addepalli at oracle.com>; 
>>>>>>> swing-dev at openjdk.java.net
>>>>>>> *Subject:* Re: <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid 
>>>>>>> position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>>
>>>>>>> Thanks Krishna for your comment. Modified webrev catering to 
>>>>>>> retrieval of scalefactor of the active monitor being shown
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.01/ 
>>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.01/>
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>>
>>>>>>> On 3/20/2018 2:40 PM, Krishna Addepalli wrote:
>>>>>>>
>>>>>>>     Hi Prasanta,
>>>>>>>
>>>>>>>     I have couple questions regarding your fix:
>>>>>>>
>>>>>>>     1.The AffineTransform object should be retrieved from the Screen
>>>>>>>     on which the window is showing, whereas in your fix, you are
>>>>>>>     directly getting it from the default screen. In multi screen
>>>>>>>     environment, it may not be aligned correctly.
>>>>>>>
>>>>>>>     2.Is there any reason to retrieve the object in the top. I mean,
>>>>>>>     the AffineTransform object can be declared inside the “if
>>>>>>>     (haveActiveClient())” block, at the point of use.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>
>>>>>>>     Krishna
>>>>>>>
>>>>>>>     *From:*Prasanta Sadhukhan
>>>>>>>     *Sent:* Tuesday, March 20, 2018 1:01 PM
>>>>>>>     *To:* swing-dev at openjdk.java.net 
>>>>>>> <mailto:swing-dev at openjdk.java.net>
>>>>>>>     *Subject:* <Swing Dev> [11] RFR JDK-8189687:Swing: Invalid
>>>>>>>     position of candidate pop-up of InputMethod in Hi-DPI on Windows
>>>>>>>
>>>>>>>     Hi All,
>>>>>>>
>>>>>>>     Please review a fix for an issue where it is seen that
>>>>>>>     for Japanese IME on windows 10 with scaleFactor 1.5, when we 
>>>>>>> enter
>>>>>>>     text using IME popup, the popup is positioned on top of text,
>>>>>>>     thereby obscuring it
>>>>>>>     as seen in this screenshot.
>>>>>>>
>>>>>>>
>>>>>>>     Proposed fix is to apply the scaleFactor on the candidate's 
>>>>>>> popup
>>>>>>>     positional coordinates x,y to generate proper coordinates to 
>>>>>>> show
>>>>>>>     this popup
>>>>>>>     webrev: 
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8189687/webrev.00/
>>>>>>> <http://cr.openjdk.java.net/%7Epsadhukhan/8189687/webrev.00/>
>>>>>>>
>>>>>>>     The screenshot after the fix is
>>>>>>>
>>>>>>>
>>>>>>>     Regards
>>>>>>>     Prasanta
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
> 

-- 
Best regards, Sergey.