<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