[OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Thu Nov 12 13:02:42 UTC 2015


This version looks fine.
A few notes which we discussed offline:
- It will be good to understand how SG2D.copyarea should work in case of 
transformed graphics.
- The different types of embedding should be checked(plugin,swt,fx).
- I suggest to run some benchmarks to figure out what performance 
penalty we will get.

On 10.11.15 16:07, Alexander Scherbatiy wrote:
> On 11/7/2015 3:56 AM, Jim Graham wrote:
>> It looks like the only remaining issues are:
>>
>> - Should we scale the origin of the screens so that they remain adjacent?
>
>      The Toolkit defines only methods that allows to get size of the the
> primary screen and screen insets which are rescaled in the provided fix.
>      The XGraphicsConfiguration bounds are also rescaled.
>
>>
>> Questions that remain and may end up getting handled under followon bugs:
>>
>> - We should really think through rounding issues better in scaleDown()
>> - We need to see if there can be a more accurate way to handle
>> applyShape(Region) at the device scale.
>> - DPI_SCALE needs to be handled eventually, don't let it fall through
>> the cracks
>> - Other Linux DPI attributes should be handled, hopefully there is a
>> bug filed for that
>>
>> Some of those could be simply left for feedback from developers, but
>> what is our plan to get our developers to do a decent amount of
>> testing with their applications to let us know if our choices were fine?
>>
>> More comments inline below:
>>
>> On 11/6/15 2:00 AM, Alexander Scherbatiy wrote:
>>>
>>>   Could you review the updated fix:
>>>     http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/
>>>
>>>    - pixbuf is freed in the awt_Robot.c
>>>    - screenWidth/Height is rescaled in the XToolkit.initScreenSize()
>>> method
>>
>> Is there also a position that needs to be adjusted?  Is the convention
>> that all screens should be directly adjacent, or can they float with
>> gaps between them?
>
>     The toolkit does not provide method to get the primary screen position.
>     I thought about adjusting screens with different scaling but it
> looks like it is an additional task which can be handled in a separated
> bug.
>>
>>>    See more comments inline:
>>>
>>>>> In XComponentPeer we shouldn't be scaling a region, we should have
>>>>> created the region in a scaled coordinate system...
>>>
>>>        Could you give more details on this?
>>>        For example, we create a frame which is twice bigger than the
>>> original one for the scale 2.
>>>        For  this case it needs to scale the shape twice. The lox, loy,
>>> hix, hiy values are calculated correctly.
>>>        The native function XShapeCombineRectangles is used to draw the
>>> final shape for the given window.
>>
>> I suppose it may be architecturally difficult to do at this point, but
>> ideally a Region should be a create-only structure that is produced at
>> the desired device coordinate system and scaling.  It might be
>> necessary to perform integer translates on it as windows are moved
>> around the screen from one integer location to another, but it should
>> never be scaled.  The fact that there is a method that can scale a
>> region is basically an admission that we have not always done the
>> right thing with respect to creating regions at device resolution.
>>
>> It looks like this may be the path of least resistance currently, but
>> if we can improve the architecture to allow the Region to maintain
>> full device resolution and not require any scaling that would be far
>> better.
>
>     I see now.
>>
>>>>> In XDragSourceContextPeer, should the scaledown try to do rounding?
>>>>> Also, XMouseInfoPeer, lines 71,72?
>>>>> Also, XToolkit, lines 725,726,855-858?
>>>>> Also, XlibUtil, lines 129-131,159?
>>>>> Also, X11GraphicsConfig, line 272?
>>>         I changed this to use scaleDown(x, scale) method from the
>>> XlibUtil.
>>>         However, I am not sure about rounding. Only integer scale values
>>> can be used. In this case x / 2 (3, 4, ...) returns a rounding to the
>>> smallest value
>>>         which is what we probably need.
>>
>> The fact that only integer scaling values can be used only makes
>> scaling up easier.  It still begs the question of what value to report
>> when we end up with X.5 or X.75 - should that be X or X+1?
>>
>> Why is truncation/rounding down what we need?  Where is the analysis
>> of how application behavior will be affected by rounding down vs.
>> rounding up or rounding evenly?
>>
>> Note that in FX we have a number of different coordinate snapping
>> functions that perform different rounding operations.  Some are for
>> sizes of things, some are for locations, and some are for calculating
>> distributed distances during layout.
>
>      It could be better to move the question about location, sizes and
> distances scaling to a separate bug. The same question I also have for
> the Windows HiDPI Graphics support.
>
>    Thanks,
>    Alexandr.
>
>>
>>>>> awt_GraphicsEnv.c - what about GDK_DPI_SCALE?  It seems like it
>>>>> might be
>>>>> used to compensate for fonts on HiDPI screens that are already scaled
>>>>> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the
>>>>> fonts.  I'm not entirely sure I understand that, though, but it bares
>>>>> further investigation...
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8058742
>>>>
>>>> may be related to this GDK_DPI_SCALE issue...
>>>      I think yes.  The GDK_DPI_SCALE can be used in the JDK-8058742 fix
>>> to rescale GTK L&F UI sizes so they look in the same way as other L&Fs.
>>>      And the GDK_SCALE is used in the current fix to scale all UI.
>>>      It looks like there is no need to use the GDK_DPI_SCALE  in the
>>> current fix and I would prefer to not mix the current fix with the
>>> JDK-8058742.
>>
>> OK, as long as we are aware of it and tracking it.  It sounds like
>> GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought
>> that they'd be implemented as part of the same fix, but as long as we
>> get to it sooner rather than later, that's fine.
>>
>>>>> Also, is GDK_SCALE the only platform scale factor that Linux/X11
>>>>> might use?
>>>
>>>        I used only GDK_SCALE in this fix. If there is another scale
>>> factors it would be better to add them in another fix.
>>
>> True.  I included this link in my HiDPI talk which appears to be a
>> fairly comprehensive list:
>>
>> https://wiki.archlinux.org/index.php/HiDPI
>>
>>                 ...jim
>


-- 
Best regards, Sergey.



More information about the 2d-dev mailing list