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

Philip Race philip.race at oracle.com
Wed Nov 2 22:58:06 UTC 2016


OK but I think a code comment in an answer to Sergey's question is 
warranted -
explaining how the "new" thread is needed because of displayChanged
making a synchronous call on to the toolkit thread.
Otherwise it looks quite odd on its own.

Also make sure this is tested both with & without D3D.

-phil.

On 6/30/16, 10:21 AM, Semyon Sadetsky wrote:
> On 5/31/2016 10:12 PM, Phil Race wrote:
>> 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.
> Because we always use D3DGraphicsDevice if d3d is available.
> new D3DGraphicsDevice()-> getDeviceCaps()-> 
> D3DRenderQueue.flushAndInvokeNow()->
> flushBuffer()-> 
> D3DRenderQueue.cpp->AwtToolkit::GetInstance().InvokeFunction()->::SendMessage()
>
> It may cause a deadlock if the displayChange event is handled on the 
> Toolkit thread.
>
> --Semyon
>>
>> -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/20161102/2bb9ed34/attachment.html>


More information about the awt-dev mailing list