On Thu, 8 Jun 2023 21:35:45 GMT, Sergey Bylokhov <s...@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
