<AWT Dev> [9] Review request for 8163101: dual-screen issue with JMenu, JPopupMenu

Semyon Sadetsky semyon.sadetsky at oracle.com
Mon Nov 7 16:48:33 UTC 2016



On 11/7/2016 6:53 PM, Sergey Bylokhov wrote:
> On 07.11.16 18:37, Semyon Sadetsky wrote:
>>> This is the question why it is unsupported, since Unity can set
>>> different dpi per screen.
>> It doesn't work. It only scales the Unity top panel and the launcher.
>> Apps windows have always the same scale equals to the main screen scale.
>
> There is an option to scale the size of the window to the biggest or 
> smallest scale of the screen, which is not necessary the main screen 
> But this is unrelated to this fix.
>
>>> But this is unrelated. We support a different GraphicsDevice per
>>> screen, each device should have its own scale(even if it is the same
>>> value). The code which operates on screen bounds should use its own
>>> graphics device.
>> Nope. Java does not support different scales for monitors. Attempt to
>> set them different when Xinerama is used will cause unpredictable 
>> behavior.
>
> This is unrelated, the code should depends on bounds/scales/etc from 
> device where the popup or window are located.
Originally, the code was written in the present state. And it has been 
working fine all the time. Changing the design is out of the scope of 
this issue. This issue is about regression that is caused by the change 
which didn't improve design in the way you want it. So, the regression 
should be fixed, it is mandatory action because the regression was 
introduced in 9. The rest improvement are optional and may be postponed. 
Is it clear to you?
>
>>>>>> I proposed to do same to investigate the problem. Does it mean that
>>>>>> you
>>>>>> approve the current fix?
>>>>>
>>>>> No, this is one is a separate bug. and I already described why.
>>>> But do you have any other concerns to the current fix?
>>>
>>> The code in question should use the bounds of the screen where the
>>> component is located, not a bounds of the main screen.
>>>
>>>>>
>>>>>> But severity of this bug is rather low because it is internal 
>>>>>> problem
>>>>>> that does not affect user experience. It may be deferred to the next
>>>>>> major JDK release.
>>>>>>
>>>>>> Also note, that the same bug was already closed as "won't fix" 
>>>>>> before:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-5100801
>>>>>>
>>>>>> --Semyon
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



More information about the awt-dev mailing list