<AWT Dev> [OpenJDK 2D-Dev]  Review request for 8137571 Linux HiDPI Graphics support
alexandr.scherbatiy at oracle.com
Tue Nov 10 13:07:27 UTC 2015
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:
>> - pixbuf is freed in the awt_Robot.c
>> - screenWidth/Height is rescaled in the XToolkit.initScreenSize()
> 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
>> 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
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
>> 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.
>>>> 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...
>>> 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
> 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:
More information about the awt-dev