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

[Prasanta Sadhukhan]

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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>