On 11.12.2013 15:46, 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?
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.
I checked it on a native application and at least on my configuration
osx changes the size of window, if it was moved from big screen to the
small screen.
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.
--
Best regards, Sergey.
