<Swing Dev> [13] RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated

Prasanta Sadhukhan prasanta.sadhukhan at oracle.com
Fri Apr 12 10:00:38 UTC 2019


HI Jay,

Thanks for your review.
On 12-Apr-19 2:50 PM, Jayathirth Rao wrote:
> Hi Prasanta,
>
> I was going through the trail of changes related to this fix.
>
> In JDK-8178025 changes are made to update the BasicTooTipUI renderer 
> when there is “graphicsConfiguration” property is changed and also we 
> have updated GlyphPainter1 to get proper FontMetrics if there is 
> mismatch between Container FM and default FM. Apart from this we have 
> modified code to return floating point width GlyphPainter1.getSpan().
>
> After this under JDK-8191428 floating point width calculation of 
> GlyphPainter1.getSpan() is reverted as it has caused a regression. 
> Even after JDK-8191428 change, you have mentioned that JDK-8178025 
> regression test GetSpanHiDpiBug.java is not failing. Is it because 
> font metrics update done in sync() method is enough to get proper span?
>
Yes, and also BasicHTML.updateRenderer() was called due to GC change in 
BasicLabelUI which cause html to recreate the text viacreateHTMLView() 
using proper span .
> Also in JDK-8201552, we have modified the way in which we update 
> renderer in propertyChange() using SwingU2.isScaleChanged() instead of 
> firing event in all cases where “graphicsConfiguration” is the 
> property change. Will this in anyway modify the previously expected 
> behaviour?
I believe JDK-8201552 catches "graphicsConfiguration" property event in 
SwingU2.isScaleChanged() and updates if there is a change in "scale", 
which anyway is what "graphicsConfiguration" property was introduced for,
so I think it will not modify behavour prior to JDK-8201552 and after 
JDK-8178025 fix.
>
> Overall it looks like we are getting different scale values from 
> Component.getFont.getTransform() compared to getting scale values 
> directly from GC. May be we are not updating font properties when 
> there is GC change.
>
> Also in the present change do we need to scale insets of the rectangle 
> along with width and height?
I am updating the whole "paintTextR" rectangle needed to contain the 
tooltip text which already has insets calculated in it.

Regards
Prasanta
>
> Thanks,
> Jay
>
>> On 29-Mar-2019, at 3:07 PM, Prasanta Sadhukhan 
>> <prasanta.sadhukhan at oracle.com 
>> <mailto:prasanta.sadhukhan at oracle.com>> wrote:
>>
>> Hi All,
>>
>> Please review a fix for an issue where it is seen that HTML tooltips 
>> aren't big enough to contain their contents on Windows HiDPI 
>> displays, there by the last word of the tooltip text are missing.
>>
>> It is an aftereffect of JDK-8178025 
>> <https://bugs.openjdk.java.net/browse/JDK-8178025> where we update 
>> glyph fontMetrics if current metrics is different from Container's 
>> fontmetrics.
>> Even if the affinetransform or uiScale is modified, metrics is 
>> updated as FontMetrics would have changed because of the transform.
>> This caused the tooltip rectangle to be not able to contain the text 
>> which is drawn with modified metrics.
>> Proposed fix is to check if graphics transform has been modified 
>> because of hidpi scale, in which case, scale the tooltip rectangle 
>> accordingly.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213535
>> webrev: http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.0/
>>
>> I was not able to fashion an automated test for this, so created a 
>> manual test.
>>
>> Regards
>> Prasanta
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/swing-dev/attachments/20190412/350bed5a/attachment.html>


More information about the swing-dev mailing list