<AWT Dev> <AWT dev>[9] Review request for 8061637: GraphicsEnvironment API does not detect dynamically attached graphics device

Semyon Sadetsky semyon.sadetsky at oracle.com
Mon May 23 10:29:50 UTC 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160523/da38a319/attachment.html>


More information about the awt-dev mailing list