On 5/23/2016 10:31 AM, Sergey Bylokhov wrote:
I guess calling the SGE.displayChanged() on some random thread is
incorrect, there is no any synchronization, so these threads can be
executed in parallel, and
I agree the synchronization is required for
Win32GraphicsEnvironment#displayChanged()
this can cause more issues if some client code can be executed on this
thread. It seems the right fix would be:
- Check that there is no any client code on this path(including all
listeners).
User code is not supposed to be called on the display change except for
the device level listeners.
- Updates the internal state of SGE on the toolkit thread.
This will not be possible because of deadlock: the SGE update calls D3D,
which synchronously send messages to the toolkit thread.
- Notify all listeners on related EDT(if there is some users code) or
directly on the toolkit thread if there is only our code.
Yes, the window's listeners should be called on the EDT they belong to.
But the window peer does not implement that on Windows. It should be fixed.
Other listeners are not supposed to call the user code and since the
system EDT is absent there are no other way to execute them.
I think that XToolkit and LWToolkit should uses this logic already.
On Windows communication with the graphics pipeline is designed differently.
--Semyon
On 29.04.16 9:56, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8061637
webrev: http://cr.openjdk.java.net/~ssadetsky/8061637/webrev.00/
Display reconfiguration notification is skipped by JavaWS and the plugin
under Windows.
This happens because native display change event is scheduled to the
main app context EDT but the last was disabled by 8004584. As result NPE
is thrown on the Toolkit thread and event handling is not scheduled.
The fix solution runs display event handling in a new thread if the
system EDT is not available.
Test would require to write native code so the bug is labeled
noreg-hard.
--Semyon
