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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Tue Nov 14 20:08:55 UTC 2017


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.



More information about the swing-dev mailing list