<Swing Dev> [9] Review request for 8046031: UI of Java Web Start app isn't updated when changing Windows theme

[Semyon Sadetsky]

On 4/28/2016 3:57 PM, Sergey Bylokhov wrote:
> On 27.04.16 10:11, Semyon Sadetsky wrote:
>>> All of these are a private object fields in Windows l&F and the l&f is
>>> stored per appcontext. what is the problem in these fields?
>> The problem is performance. They may trigger the property change and
>> then update all context's UI's. The last is rather heavy operation, so
>> if next property update request come and isUpdatePending() is true then
>> the new overall UI update event is not posted.
>
> ok, then just make the new field private and do not use the interned 
> string as a key.
Why do you think it should be private? This flag may be used as a sign 
of the upcoming  global UI update.

--Semyon
>
>>
>> --Semyon
>>>
>>>>
>>>>              this.themeActive = new
>>>> TriggerDesktopProperty("win.xpstyle.themeActive");
>>>>              this.dllName     = new
>>>> TriggerDesktopProperty("win.xpstyle.dllName");
>>>>              this.colorName   = new
>>>> TriggerDesktopProperty("win.xpstyle.colorName");
>>>>              this.sizeName    = new
>>>> TriggerDesktopProperty("win.xpstyle.sizeName");
>>>>
>>>> --Semyon
>>>>>
>>>>>> Putting the flag into the app scope protects from scheduling events
>>>>>> recursively
>>>>>>> If the Appcontext is necessary, then we should not use interned
>>>>>>> string
>>>>>>> as a key, I suggest to use the simple new Object(), so it will 
>>>>>>> not be
>>>>>>> accessible outside of this class.
>>>>>> This is a public field. Accessing it outside the class shouldn't 
>>>>>> be an
>>>>>> issue.
>>>>>
>>>>> I overlooked that it is public in my first email. Why? If it is not
>>>>> used outside of this class it should be private. Also the interned
>>>>> string will provide a way to access this data even if
>>>>> "com/sun/java/swing" package will be inaccessible. So it is better to
>>>>> use private key.
>>>>>
>>>>>>
>>>>>> --Semyon
>>>>>>>
>>>>>>> On 21.04.16 16:56, Alexandr Scherbatiy wrote:
>>>>>>>>
>>>>>>>>   The fix looks good to me.
>>>>>>>>
>>>>>>>>   Thanks,
>>>>>>>>   Alexandr.
>>>>>>>>
>>>>>>>> On 4/21/2016 6:22 AM, Semyon Sadetsky wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review fix for JDK9:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8046031
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8046031/webrev.00/
>>>>>>>>>
>>>>>>>>> Under the Windoew LnF when the native Windows theme is changed 
>>>>>>>>> some
>>>>>>>>> java frames remains unchanged if there are several application
>>>>>>>>> contexts. The thing is the DesktopProperty#updatePending flag 
>>>>>>>>> that
>>>>>>>>> prevents to run more then one UI update operation is shared 
>>>>>>>>> between
>>>>>>>>> different applications contexts while they may be updated with 
>>>>>>>>> the
>>>>>>>>> property change concurrently from different EDT threads so 
>>>>>>>>> they may
>>>>>>>>> loose the update.
>>>>>>>>> To avoid this mutual interference the updatePending is moved
>>>>>>>>> from the
>>>>>>>>> global to the application context scope.
>>>>>>>>> The test would require to write native code so the issue is 
>>>>>>>>> labeled
>>>>>>>>> noreg-hard.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>