<Swing Dev>  RFR JDK-8213535:Windows HiDPI html lightweight tooltips are truncated
prasanta.sadhukhan at oracle.com
Fri Apr 12 11:52:39 UTC 2019
On 12-Apr-19 3:30 PM, Prasanta Sadhukhan wrote:
> 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
> 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.
Not sure on this whether we should update the Component font's
transform. As this issue is primarily for html text in tooltip (ie it
does not occur if tooltip uses normal text) which means
has already updated the html text ('s span) due to GC change, so only
thing we can do is to update the rectangle size to contain the updated text.
>> 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.
>>> 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
>>> 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
>>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swing-dev