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

[Prasanta Sadhukhan]

On 02-Apr-20 10:04 PM, Prasanta Sadhukhan wrote:
>
> On 02-Apr-20 9:45 PM, Sergey Bylokhov wrote:
>> On 4/1/20 1:03 am, Prasanta Sadhukhan wrote:
>>> It is because of the same issue the size is not updated as 
>>> ToolTipManager#showTipWindow() calls popupFactory.getPopup() before 
>>> tip.show() and as per flow,
>>>
>>> getPopup() => getLightWeightPopup() => popup.reset() => pack() calls 
>>> component.setSize(component.getPreferredSize()) where the 
>>> preferredSize is not yet updated.
>>
>> It does not updated because it uses the wrong graphics configuration 
>> and as a result the wrong font metrics?
>> Can we set correct GC as part of reset/pack steps for the popup?
>>
> As I told, the tip is not yet shown, so the graphicsConfiguration 
> property is not yet fired so please appraise me how to set correct GC 
> in reset/pack step?
As per my understanding, the GC is correct in reset/pack steps(we pass 
insideComponent which is JButton to getPopup() and it's defaultTransform 
is same as the scale we have for the window, which in this case is 
1.25), but since "graphicsConfiguration" property is not fired, so 
BasicHTML.updateRender is not yet called so View is not yet updated, so 
the preferredSpan is not correct, which is used in preferredSize 
calculation so when setSize is called, it is set with wrong 
preferredSize, so I dont think it's because of wrong GC.
>>>
>>> Regards
>>> Prasanta
>>> On 01-Apr-20 5:11 AM, Sergey Bylokhov wrote:
>>>> That looks much better! The only question I have is why the size is 
>>>> not updated - is it intentional behaviour or we can tweak it somehow.
>>>>
>>>> On 3/31/20 1:13 am, Prasanta Sadhukhan wrote:
>>>>> View is updated by calling BasicHTML.updateRenderer when 
>>>>> "graphicsConfiguration" property is fired when tooltip is shown 
>>>>> via tip.show() in ToolTipManager. Now, we should be using the 
>>>>> updated preferredSize calculated by View.getPreferredSpan but 
>>>>> BasicToolTip#paint still uses the old size. Proposed fix is to use 
>>>>> the updated preferredSize.
>>>>>
>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.2/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 28-Mar-20 8:49 AM, Sergey Bylokhov wrote:
>>>>>> On 3/27/20 3:27 am, Prasanta Sadhukhan wrote:
>>>>>>>
>>>>>>> On 07-Dec-19 10:28 AM, Sergey Bylokhov wrote:
>>>>>>>> On 12/6/19 7:24 pm, Prasanta Sadhukhan wrote:
>>>>>>>>>> How other components which may use HTML inside calculates its 
>>>>>>>>>> preferred size? I do not remember that they additionally 
>>>>>>>>>> scale the values returned by the View.
>>>>>>>>>
>>>>>>>>> Maybe those components does not use preferredSize calculation 
>>>>>>>>> as JTooltip does.
>>>>>>>>
>>>>>>>> Even if it not used, the preferredSize of the components and 
>>>>>>>> views should return correct values.
>>>>>>>>
>>>>>>>>
>>>>>>> getPreferredSize() is called from ToolTipManager but it is done 
>>>>>>> *before *calling Tooltip.show() which actually triggers 
>>>>>>> PropertyChangeEvent with "graphicsConfiguration" property.
>>>>>>>
>>>>>>> Now, View is updated by calling BasicHTML.updateRenderer() when 
>>>>>>> "graphicsConfiguration" property is fired to notify transform is 
>>>>>>> changed, so during preferredSize() call, the View has not yet 
>>>>>>> been updated with correct transform.
>>>>>>
>>>>>> It means that the View should use GCOnfig of its 
>>>>>> parent-parent-etc, which is default/main GC if the 
>>>>>> components/windows are invisible or the GC of the real screen 
>>>>>> where the component/window is located. Or the size of the tooltip 
>>>>>> should be revalidated at the moment we found that the preferred 
>>>>>> size was calculated using the wrong GC.
>>>>>>
>>>>>> I think we should do both steps above.
>>>>>>
>>>>>>
>>>>>> Note that we should never calculate "coordinate_XY * scale" and 
>>>>>> return this value to the user. The result of "coord*scale" should 
>>>>>> be only used when we pass the data to the native code, in all 
>>>>>> other places we should use just plain coordinates in the user's 
>>>>>> space.
>>>>>>
>>>>>>> So, my proposed fix is still same
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8213535/webrev.1/
>>>>>>>
>>>>>>> Regards
>>>>>>> Prasanta
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>