[OpenJDK 2D-Dev] HiDPI support issues on Windows
james.graham at oracle.com
Sat Oct 8 00:03:34 UTC 2016
One issue is that the JViewport lastPaintPosition is exposed to subclasses and is an integer location. It is also
exposed to all apps via getViewPosition() and getViewRect(). That will conflict with indicating the exact location of
the pixel-precise scroll position. It's not clear how these will be used by subclasses and apps, or whether they can be
implemented as approximations (ViewRect() could be the smallest integer rectangle that encloses the real view bounds,
and the position could be the closest integer location to where the true pixel origin is).
One way to fix repainting issues is to disable copyArea optimizations if there is a scale. FX has had a limitation like
this until we fix our math, but our scrolling is entirely a hidden implementation detail. Given that JViewport exposes
the backbuffer and provides convenience methods for computing the blits needed to scroll, it gets a little dicey unless
the scroll mode is considered just a hint.
On 10/7/16 3:41 PM, Jim Graham wrote:
> Aren't the components inside the scrollpane located relative to the origin of the entire scrollable region? In which
> case, the precise location of the visible part of the view has no effect on any component bounds...?
> On 10/6/16 5:59 PM, Sergey Bylokhov wrote:
>> Hi, Jim.
>> Can you please clarify why the exact pixels copyarea is necessary(As well as the problem in RepaintManager) I am not
>> sure it is clear why we need to do something in the users space in floats. I mean that all our Swing components uses
>> int(units) as bounds, all of them uses integers as requests to paint, so everything in the shared code works in terms of
>> units. I am not sure that it is possible to scroll using pixel-exact copyArea because we cannot use floats to scroll by
>> this amount, otherwise we will get the situation when the component inside the scroollpane will have fractional
>> coordinate which we cannot use via int API.
>> On 07.10.16 0:21, Jim Graham wrote:
>>> 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
>>>>>> 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...
More information about the 2d-dev