<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 5/23/2016 10:31 AM, Sergey Bylokhov wrote:<br>
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite">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</blockquote>
    I agree the synchronization is required for
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    Win32GraphicsEnvironment#displayChanged()
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite"> this can cause more issues if some client code can be
      executed on this thread. It seems the right fix would be:
      <br>
       - Check that there is no any client code on this path(including
      all listeners).
      <br>
    </blockquote>
    User code is not supposed to be called on the display change except
    for the device level listeners.<br>
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite"> - Updates the internal state of SGE on the toolkit
      thread.
      <br>
    </blockquote>
    This will not be possible because of deadlock: the SGE update calls
    D3D, which synchronously send messages to the toolkit thread.<br>
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite"> - Notify all listeners on related EDT(if there is
      some users code) or directly on the toolkit thread if there is
      only our code.
      <br>
    </blockquote>
    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.<br>
    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.<br>
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite">
      <br>
      I think that XToolkit and LWToolkit should uses this logic
      already.
      <br>
    </blockquote>
    On Windows communication with the graphics pipeline is designed
    differently.<br>
    <br>
    --Semyon<br>
    <blockquote
      cite="mid:af304deb-bea7-1fd8-36bb-b77088c94ff8@oracle.com"
      type="cite">
      <br>
      On 29.04.16 9:56, Semyon Sadetsky wrote:
      <br>
      <blockquote type="cite">Hello,
        <br>
        <br>
        Please review fix for JDK9:
        <br>
        <br>
        bug: <a class="moz-txt-link-freetext" href="https://bugs.openjdk.java.net/browse/JDK-8061637">https://bugs.openjdk.java.net/browse/JDK-8061637</a>
        <br>
        webrev: <a class="moz-txt-link-freetext" href="http://cr.openjdk.java.net/~ssadetsky/8061637/webrev.00/">http://cr.openjdk.java.net/~ssadetsky/8061637/webrev.00/</a>
        <br>
        <br>
        Display reconfiguration notification is skipped by JavaWS and
        the plugin
        <br>
        under Windows.
        <br>
        This happens because native display change event is scheduled to
        the
        <br>
        main app context EDT but the last was disabled by 8004584. As
        result NPE
        <br>
        is thrown on the Toolkit thread and event handling is not
        scheduled.
        <br>
        The fix solution runs display event handling in a new thread if
        the
        <br>
        system EDT is not available.
        <br>
        Test would require to write native code so the bug is labeled
        noreg-hard.
        <br>
        <br>
        --Semyon
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>