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

[Jim Graham]

It looks like the only remaining issues are:

- Should we scale the origin of the screens so that they remain adjacent?

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?

>    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.

>>> 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.

>>> 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