<Swing Dev> [10] RFR JDK-8178025:HiDPI with non-integer scale factor - SPANs in HTML are rendered overlapping each other

[Sergey Bylokhov]

Looks fine, thank you.

On 14/11/2017 21:57, Prasanta Sadhukhan wrote:
> Hi Sergey,
> 
> Ok. Updated test to move to 1st screen and then to 2nd screen
> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.09/
> 
> Regards
> Prasanta
> On 11/15/2017 1:38 AM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> I checked the test and it fails on my environment, and the reason is 
>> that I have the main screen on the right and the second screen on the 
>> left, which means that the test moves the window outside of any 
>> screens. But it should move the window to one screen and then to 
>> another screen.
>> Small issues "f.dispose();" is called on non-EDT thread.
>>
>> On 13/11/2017 23:58, Prasanta Sadhukhan wrote:
>>> Hi Sergey,
>>>
>>> Updated webrev to use setBounds() instead of robot in test
>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.08/
>>>
>>> Regards
>>> Prasanta
>>> On 11/14/2017 4:13 AM, Sergey Bylokhov wrote:
>>>> Hi, Prasanta.
>>>> I have only comment about the test. Why it uses robot, I think that 
>>>> the setBounds() to another screen should be enough?
>>>>
>>>> On 08/11/2017 23:13, Prasanta Sadhukhan wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Please find updated webrev which changes "graphicsConfig" 
>>>>> notification to "graphicsConfiguration". Added auto test for this 
>>>>> property and also fire the notification after the change.
>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.07/
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>> On 11/8/2017 11:11 AM, Prasanta Sadhukhan wrote:
>>>>>>
>>>>>>
>>>>>> On 11/8/2017 2:01 AM, Sergey Bylokhov wrote:
>>>>>>> On 07/11/2017 02:55, Prasanta Sadhukhan wrote:
>>>>>>>> AFAIK, all client property are by default "public" and I do not 
>>>>>>>> see any documentation of any other property too. Do you see any 
>>>>>>>> other property being documented in our javadoc?
>>>>>>>
>>>>>>> They are "public" but it does not mean that all of them are 
>>>>>>> specified. Of-course it is unlikely to change, but it should be 
>>>>>>> taken into account.
>>>>>>>
>>>>>>> Small comments about the fix:
>>>>>>>  - Why we fire the notification before the actual change? I 
>>>>>>> suggest to create at least one auto test to check the behavior of 
>>>>>>> new property.
>>>>>> I guess I am firing after the graphicsConfig has been changed from 
>>>>>> what it was last time ie, after
>>>>>> if (graphicsConfig == gc) {
>>>>>>             return false;
>>>>>>         }
>>>>>> If the graphicsConfig has not changed, it will not fire the 
>>>>>> notification.
>>>>>> Also, I amnot sure how to go about this auto test as I am not sure 
>>>>>> how to change graphicsConfig automatically.
>>>>>>>  - What about other classes which call BasicHTML.updateRenderer() 
>>>>>>> in a propertyChange? for example: BasicToolTipUI, SynthToolTipUI, 
>>>>>>> BasicButtonListener.
>>>>>> Yes, these needs to be updated as well.
>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.06/
>>>>>>
>>>>>> Regards
>>>>>> Prasanta
>>>>>>>
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Prasanta
>>>>>>>> On 11/7/2017 7:37 AM, Alan Snyder wrote:
>>>>>>>>> Is “graphicsConfig” a new public client property? I don’t see 
>>>>>>>>> it documented anywhere.
>>>>>>>>>
>>>>>>>>> I think it should be public, or some public equivalent is 
>>>>>>>>> needed, because there are cases where applications need to 
>>>>>>>>> recompute a layout after the graphics configuration changes.
>>>>>>>>>
>>>>>>>>>    Alan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Oct 30, 2017, at 11:12 PM, Prasanta Sadhukhan 
>>>>>>>>>> <prasanta.sadhukhan at oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Ok. Modified webrev to make sure data is recalculated by 
>>>>>>>>>> listening to "graphicsConfig" change
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~psadhukhan/8178025/webrev.03/
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Prasanta
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.