Hi Sergey,
The fix looks good to me.
--
best regards,
Anthony
On 12/11/2013 04:35 PM, Sergey Bylokhov wrote:
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.
