[OpenJDK 2D-Dev] HiDPI support issues on Windows
james.graham at oracle.com
Fri Oct 7 22:41:30 UTC 2016
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