<AWT Dev> [8] Review Request: 8027778 [macosx] Full screen not working properly on 7u45 with 10.7

[Sergey Bylokhov]

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 <Sergey.Bylokhov at oracle.com> 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 <Sergey.Bylokhov at oracle.com> 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.