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
