RFR: 8006421: GraphicsConfiguration of a frame is changed when the frame is moved to another screen

[Tejesh R]

On Thu, 8 Jun 2023 21:35:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> > > > > We should check why that code does not work, note the code in that patch also support both Window and Canvas.
>>> > > > 
>>> > > > 
>>> > > > We can use `getAppropriateGraphicsConfiguration()` of `XCanvasPeer` class, which solves the problem. We can use it whenever new screen is set/new screen GC is set (Not sure of why it wasn't used before). The old code gets defaultGC whenever screen switch happens. We can use the existing implementation, which is actually better than selecting TransparencyCapable GC alone. Their exist a regression for this re-use solution i.e., test [WindowGCChangeTest.java](https://github.com/openjdk/jdk/blob/master/test/jdk/java/awt/Multiscreen/WindowGCChangeTest/WindowGCChangeTest.java), which is basically windows specific test.
>>> > > 
>>> > > 
>>> > > If think that method should work even before the fix. In the peer we set the GC to some value we found, then call Component.setGraphicsConfiguration() which for canvas and window should call getAppropriateGraphicsConfiguration. Why it does not work?
>>> > 
>>> > 
>>> > In Window, GC is set when during initialization, i.e., `initGC()` is called, also there is separate `setGraphicsConfiguration() ` method. But unlike `Canvas.setGraphicsConfiguration()`, in window `getAppropriateGraphicsConfiguration()` is not used. So with Window, unlike Canvas setting a GC is quite different and doesn't involve `getAppropriateGraphicsConfiguration()` I hope.
>>> 
>>> So this bug is not reproduced for Canvas? Then probably we should use the code similar to Canvas.setGraphicsConfiguration in the WIndow class?
>> 
>> Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.
>
>> Can't be sure of both. Because `getAppropriateGraphicsConfiguration()` is used only if initialization of GC during `initGC` fails, i.e., `GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();` fails to load GC. Moreover in this bug we are trying to address the switch over between screen, hence my fix is in Peer component. So adding a similar code in Window class might not be a fix, rather we **might** have to change the way GC is loading from initialization too.
> 
> The patch which added the getAppropriateGraphicsConfiguration was supposed to fix the same bug but looks like it was implemented for the Canvas only, I think we can do the same thing for the Window class as well. Note that getAppropriateGraphicsConfiguration on all other platforms is noop so it should not affected.

@mrserb I have updated the PR with Canvas Patch with @azvegint as reviewer. Please let me know if you have anything else about this PR? (CI testing is green).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14246#issuecomment-1596565644