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...?
...jim
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)...
...jim
On 10/6/16 3:11 AM, Anton Tarasov wrote:
Hi all,
On 04 Oct 2016, at 23:28, Jim Graham <james.gra...@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.
