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

[Phil Race]

I am not very familiar with this code, but why is this discussion 
centred around D3D?
The GDI pipeline is just as "popular" on Windows due to Intel chipsets.

-phil.

On 05/23/2016 07:36 AM, Semyon Sadetsky wrote:
>
>
> On 5/23/2016 5:00 PM, Sergey Bylokhov wrote:
>> On 23.05.16 13:29, Semyon Sadetsky wrote:
>>> This will not be possible because of deadlock: the SGE update calls 
>>> D3D,
>>> which synchronously send messages to the toolkit thread.
>>
>> Why it is a problem to call this on the toolkit thread directly?
> This is how D3D calls are run : sun.java2d.d3d. 
> D3DRenderQueue#flashBuffer uses 
> AwtToolkit::GetInstance().InvokeFunction().
>
> --Semyon
>>
>>>> I think that XToolkit and LWToolkit should uses this logic already.
>>> On Windows communication with the graphics pipeline is designed 
>>> differently.
>>
>> They are quite similar if not identical. I suggest to check two 
>> solutions:
>>  - displayChanged is on toolkit thread, only listeners which can call 
>> users code executed on EDT.
>>  - The main logic on the toolkit thread all listeners are on related 
>> EDT(in this case we will need to save the appcontext of the listener 
>> on addDisplayChangedListener()).
>>
>>>
>>> --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/20160531/41b8de61/attachment-0001.html>