[OpenJDK 2D-Dev] HiDPI support issues on Windows

Jim Graham james.graham at oracle.com
Thu Oct 6 21:21:48 UTC 2016

Yes, most likely.  It involves making sure that the origin of the viewport is always an even multiple of pixels, then 
the copyArea will match up with the repainting.  The damage repair messages here have already pointed out how to deal 
with making sure the repaints are on integer coordinates, the only tricky part is that there is no floating point 
copyArea method (copyArea used to not allow copying with anything other than a translation, but we fixed that for Mac, 
but the fix really only works for integer scales and, while it does do something sane for non-integer scales, it doesn't 
really provide the caller full precision for controlling which pixels are copied).  To do a pixel-exact copyArea you 
would need to undo the transform, calculate the scaled pixel locations yourself, then do a non-scaled copyArea and then 
restore the transform (or do the operation on a copy of the graphics)...


On 10/6/16 3:11 AM, Anton Tarasov wrote:
> Hi all,
> On 04 Oct 2016, at 23:28, Jim Graham <james.graham at oracle.com> wrote:
>> On 10/4/16 1:01 PM, Anton Tarasov wrote:
>>> Anyway, I roughly tried your approach mentioned in the previous e-mail, but forcing RM to paint via offscreen
>>> BufferedImage, not volatile (just for a quick check).
>>> It solved the shift issue of the demo listed in 8162350, which is cool. It also solved the traces of InternalFrame and
>>> menu in SwingSet2. Scrolling still traces (I suppose it should be resolved in JViewport/blitting).
>>> Also, the problem with primitives rendering (http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png) is
>>> still there. But it seems to relate to line-thikness (border-thickness) rounding inaccuracy. What we can do with that?...
>> Yes, blitting is a separate, but related case where pixel-exactness matters.  When we scroll a pane we need to scroll it by a precise number of pixels and then paint the newly visible information at a precise pixel location.  Solving this aspect might require events to have higher precision data available.
>> We should probably take detailed conversations about the solutions to the bug reports…
> What do you think, is it possible to address the mentioned issues in jdk9, not deferring them? The new HiDPI support will affect all the users having fractional scale screens...
> Thanks,
> Anton.

More information about the 2d-dev mailing list