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
