<AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu 15.10

[Semyon Sadetsky]

On 05.10.2016 01:53, Sergey Bylokhov wrote:

> On 04.10.16 16:27, Semyon Sadetsky wrote:
>> On 10/4/2016 4:05 PM, Sergey Bylokhov wrote:
>>
>>> Hi, Semyon.
>>>   - It seems that DisplayMode contain the data which were not upscaled
>>> to the units instead of pixels. It seems incorrect that it is
>>> necessary to convert them here to set the correct size for the window.
>> Not sure that it is true. Display mode is a device attribute. It should
>> be the same as the one presented in the native system configuration.
>
> But the units in which we reports this values are important, right now 
> there is no any API which reports something related to display in 
> pixels(insets,bounds, and probably modes.) It seems that display modes 
> are ovelooked when HiDPI was pushed. Do DisplayMode we can report 
> pixels or units but the same for all platforms. So we can discass it 
> in separate bug. Why in this case we cannot use the bounds of the 
> graphicsCondiguration? It should be the same as dm.w/scale.
The DisplayMode size has been always used, I did not change that. I 
guess it is because GC.getBounds() returns RootWindow bounds but we want 
to be closer to the hardware level and avoid WM mediation.
>
>>>   - Is it possible to eliminate check for Unity? I guess that if the
>>> size of mode and currentwindow are different then the window should be
>>> reshaped unconditionally is unity used or not.
>> It is not necessary for other Linux OSes because this transitional size
>> updates happen only on Unity. Since this WM behavior is undocumented I
>> prefer to have an accurately addressed fix.
>
> Why? If the size was changed and the frame is in fullscreen then we 
> should change the size of the window to screen bounds. It is better 
> than have a wm specific ifs.
I already explained why. It is Unity specific. Such change would require 
to test all other WMs because it is about unspecified behavior. Since 
the issue only exits in Unity we don't need to do this extra work and to 
take extra risk.
>
> Do you know why the code in X11GraphicsDevice.setDisplayMode() does 
> not work?:
>         // update bounds of the fullscreen window
>         w.setBounds(0, 0, dm.getWidth(), dm.getHeight());
I explained this already. In Unity changing display mode starts a 
transitional phase during which the windows size and position are 
updated several times. So, after the line above is executed size is 
changed by WM again.
>
>
>>>
>>> ----- alexander.zvegintsev at oracle.com wrote:
>>>
>>>> Looks fine.
>>>>
>>>> -- 
>>>> Thanks,
>>>> Alexander.
>>>>
>>>> On 10/03/2016 07:38 PM, Semyon Sadetsky wrote:
>>>>> The fix is updated
>>>>> http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.01/
>>>>>
>>>>> The root case of the issue is that in Unity the screen window size
>>>> and
>>>>> location are get updated several times after display mode is
>>>> changed,
>>>>> and bounds which are set in line 459 of X11GraphicsDevice class are
>>>>> overwritten. Since those window updates caused by display mode
>>>> change
>>>>> are not predictable the solution is changed to set the correct
>>>>> full-screen size in the ConfigureNotify handler.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>> On 12/7/2015 2:11 PM, Semyon Sadetsky wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review fix for JDK9:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
>>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>>>>>>
>>>>>> Compiz WM requires override redirect for full-screen window to
>>>>>> preserve the full size upon display mode switching.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>
>
>