<AWT Dev> [OpenJDK 2D-Dev]  Review request for 8137571 Linux HiDPI Graphics support
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
- 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:
>>> - 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:
Best regards, Sergey.
More information about the awt-dev