<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Alexandr,<br>
    <br>
    I looked at the testcase <a moz-do-not-send="true"
      class="moz-txt-link-freetext"
      href="https://bugs.openjdk.java.net/browse/JDK-8162350">8162350</a>
    closely and found your explanation below not quite precise...<br>
    <br>
    When you repaint a letter with an slightly expanded dirty rect,
    you've got it as [40-1, 0-1, 80+2, 60+2] = [39, -1, 82, 62]. Let's
    count only "x".<br>
    As Jim noted, the code to draw is:<br>
    <br>
    // repainting x,y,w,h
    <br>
    img = make image (w,h)
    <br>
    g = img.getGraphics()
    <br>
    g.setClip(x,y,w,h)
    <br>
    g.translate(-x,-y)
    <br>
    component.paint(g)
    <br>
    destination.drawImage(img, x,y)
    <br>
    <br>
    The transformation matrix of "g" is double (AffineTransform.java).
    So, g.translate(-39) translates to -39*1.5=-58.5. The top-left pixel
    of the letter [40, 0]=[40*1.5, 0]=[60, 0] thus is painted into
    x=[60-58.5]=1.5 of the intermediate "img". And I suspect it's
    eventually not rounded up but is floor'ed to x=1. Then, the "img" is
    drawn at x=[39]=[39*1.5]=58.5 which I suspect is also eventually
    floor'ed to x=58. As the result, the top-left pixel of the letter
    appears at x=[58+1]=59, not at x=60. That's the shift. Not sure if
    my guess is correct though.<br>
    <br>
    The Jim's last suggestion seems to address the problem, as it scales
    & rounds first and then passes already computed values down.
    Does the solution affect RepaintManager only? Or I suspect there
    will be a problem with:<br>
    <br>
    // Not sure if there is a mechanism for this since I think
    <br>
    // all of the interfaces to get a compatible image are
    <br>
    // designed to assume that the caller is not scale-aware.
    <br>
    img = make pixel-sized image (pixelw, pixelh)<br>
    <br>
    because the comments are true.<br>
    <br>
    Thanks,<br>
    Anton.<br>
    <br>
    On 9/30/2016 1:22 PM, Alexandr Scherbatiy wrote:<br>
    <blockquote
      cite="mid:ae559915-f1f1-cc32-3a2b-05bb5d4b1672@oracle.com"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <br>
      Hello Anton,<br>
      <br>
      Yes, we are working on it.<br>
      <br>
      For example, there is the known issue DK-8162350 RepaintManager
      shifts repainted region when the floating point UI scale is used.<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8162350">https://bugs.openjdk.java.net/browse/JDK-8162350</a><br>
      <br>
      The problem is that the RepaintManager draws a region to a
      buffered image at first and draws the image after that to the
      window.<br>
      Suppose the image has int coordinates and size (x, y, w, h) in the
      user space. It should be drawn into the region with coordinates
      (x, y, x+width, y+height) = (x1, y1, x2, y2).<br>
      If floating point UI scale is used (like 1.5) the region
      coordinates  are converted to values (1.5 * x1, 1.5 * y1, 1.5 *
      x2, 1.5 * y2) in the dev space.<br>
      Now these coordinates need to be rounded and the process really
      depends on the evenness or oddness of the start and end
      coordinates. They both can be rounded to one side or to opposite.
      Depending on this some lines near the drawn image region can be
      not filled or just wrongly filled.<br>
      <br>
      If I try to not use a buffered image in the RepaintManager it
      seems that some problems are just gone away (internal frame moving
      artifacts on the SwingSet2 demo or squares in
      MinimalSwingApplication are drawn as squares and not rectangles).<br>
      But not all of them. The artifacts during the scrolling in the
      SwingSet2 demo still exist.<br>
      <br>
      I have filled an issue on it just to  keep track of them:
      JDK-8166954 Drawing artifacts with floating point UI scale<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8166954">https://bugs.openjdk.java.net/browse/JDK-8166954</a><br>
      <br>
      The another problem which we are working on is that a selected
      text is just shifted: 8156217 Selected text is shifted on HiDPI
      display<br>
        <a moz-do-not-send="true" class="moz-txt-link-freetext"
        href="https://bugs.openjdk.java.net/browse/JDK-8156217">https://bugs.openjdk.java.net/browse/JDK-8156217</a><br>
      <br>
      To support this we were needed to add some new API which support
      floating point coordinates in the View, TextUI and JTextComponent
      classes.<br>
      The issue is on the review: 
      <a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006705.html">http://mail.openjdk.java.net/pipermail/swing-dev/2016-September/006705.html</a><br>
      <br>
      Thanks,<br>
      Alexandr.<br>
      <br>
      <div class="moz-cite-prefix">On 9/28/2016 1:17 PM, Anton Tarasov
        wrote:<br>
      </div>
      <blockquote
        cite="mid:e773b694-40aa-513f-158d-14c67f3d0020@jetbrains.com"
        type="cite">
        <meta http-equiv="content-type" content="text/html;
          charset=utf-8">
        Hello,<br>
        <br>
        JDK9 comes with HiDPI support on Windows/Linux which is really
        great. As we gave it a try, we found it looking pretty good with
        an integer scale (2x) but revealed some rendering flaws with
        float scales.<br>
        <br>
        Let me please demonstrate it with SwingSet2 + JDK9-ea-b137 +
        Windows 8.1 in 150% scale (1.5f)<br>
        <br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/demo1.png">demo1</a><br>
        <br>
        Dragging Frame-0 behind the pallet makes the pallet wavy.<br>
        Also, as Frame-0 moves it may leave traces.<br>
        <br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/demo2.png">demo2</a><br>
        <br>
        Unstable look of a control. For instance, these two combos are
        decorated differently (and not perfectly).<br>
        <br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/demo3.png">demo3</a><br>
        <br>
        Scrolling traces.<br>
        <br>
        <a moz-do-not-send="true"
          href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/demo4.png">demo4</a><br>
        <br>
        Menu traces.<br>
        Colored rendering artifacts.<br>
        <br>
        Additionally, I'm attaching a test source & pics kindly
        provided by Renaud (cc'd) from AndroidStudio. The demo finely
        shows problems on the example of primitive rendering.<br>
        <br>
        <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-100-percent.png">Scaling
          100%</a><br>
        <br>
        <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-125-percent.png">Scaling
          125%</a><br>
        <br>
        <a moz-do-not-send="true"
href="http://cr.openjdk.java.net/%7Eant/hidpi_pics/Scaling-150-percent.png">Scaling
          150%</a><br>
        <br>
        It seems like most of the mentioned issues are caused by
        inaccurate rounding performed during the rendering cycle.<br>
        <br>
        So, I'd like to ask you please share your thoughts on it. How
        serious is the problem at all (I guess you're aware of it)? What
        is solvable on the JDK side, and what is not (e.g. demo2 and the
        Renaud's test case)?<br>
        Do you have plans to resolve it by jdk9 GA, or earlier/later?
        Any technical details behind it are very welcome as well.<br>
        <br>
        Thanks in advance,<br>
        Anton.<br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>