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

Prasanta Sadhukhan prasanta.sadhukhan at oracle.com
Wed Nov 15 05:57:24 UTC 2017


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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>




More information about the swing-dev mailing list