Hello, Sergey. >> I make the fix as simple as possible and use max(SCREEN_SIZE, >> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native >> application on 10.9 >> This is not 100% true. If you create a big window on a big screen and then >> drag it to the smaller screen - you'll get a window which is bigger than the >> screen. >> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't >> the frame automatically constrain itself to the bounds of the smaller screen >> when dragged from the bigger screen? > The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we > assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, > and it less than a screen-> we could assume that the screen size is supported > only or... what size? I agree that the we should better trust the screen size than GL_MAX_TEXTURE_SIZE, as the latter have proved that it's unreliable. In an offline discusion Sergey told me that the frame will not autoresize when it is moved to a different screen, so I'm OK with the fix now.
So, the fix look good to me. With best regards. Petr. On 11.12.2013, at 14:49, Sergey Bylokhov <[email protected]> wrote: > On 11.12.2013 11:23, Petr Pchelko wrote: >> Hello, Sergey. >> I make the fix as simple as possible and use max(SCREEN_SIZE, >> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native >> application on 10.9 >> This is not 100% true. If you create a big window on a big screen and then >> drag it to the smaller screen - you'll get a window which is bigger than the >> screen. >> So with your fix in case the GL_MAX_TEXTURE_SIZE/2 < SCREEN_SIZE, wouldn't >> the frame automatically constrain itself to the bounds of the smaller screen >> when dragged from the bigger screen? > The question is about do we trust to the GL_MAX_TEXTURE_SIZE or not, if we > assume that GL_MAX_TEXTURE_SIZE/2 is a maximum supported opengl texture size, > and it less than a screen-> we could assume that the screen size is supported > only or... what size? >> >> With best regards. Petr. >> >> On 11.12.2013, at 4:46, Sergey Bylokhov <[email protected]> wrote: >> >>> Hello. >>> Please review the fix for jdk 8. >>> Some history of the bug: >>> - Initially we did not constrain size of the window and got JDK-7160609 >>> - Then we try to use a union of the screens to constrain of the window and >>> got JDK-8015100. >>> - Then we start to use GL_MAX_TEXTURE_SIZE/2. But for some systems it was >>> too big JDK-8023159 OR too small JDK-8027778. >>> But on macosx 10.9 the windows are constrained automatically by the size of >>> the screen(Petr please confirm). >>> I make the fix as simple as possible and use max(SCREEN_SIZE, >>> GL_MAX_TEXTURE_SIZE/2<=8192), so we should behave like the native >>> application on 10.9 >>> nativeGetMaxTextureSize was moved under the render lock, where other >>> related opengl data are initialized(see >>> CGLGraphicsConfig.getCGLConfigInfo()). To me it seems safe because it works >>> in similar way in jdk7 and CGLGraphicsConfig is recreated on the each event >>> related to the screen(new resolution, new video card, etc). >>> Also I adds updateMinimumSize to the displayChanged and notifyReshape, to >>> reapply a new constrain to the window. >>> Any suggestion are welcome. >>> >>> >>> Bugs which are covered by this fix: >>> https://bugs.openjdk.java.net/browse/JDK-8027778- after the fix the maximum >>> size is not less than the screen >>> https://bugs.openjdk.java.net/browse/JDK-8015100 - we use half of the >>> GL_MAX_TEXTURE_SIZE if supported by the system, and usually it is larger >>> than the screen >>> https://bugs.openjdk.java.net/browse/JDK-8010999 - the maximum possible >>> size of the window is 8192 >>> Webrev can be found at: http://cr.openjdk.java.net/~serb/8027778/webrev.00 >>> >>> -- >>> Best regards, Sergey. >>> > > > -- > Best regards, Sergey. >
