RFR: 8270874: JFrame paint artifacts when dragged from standard monitor to HiDPI monitor
Jayathirth D V
jdv at openjdk.java.net
Mon Nov 15 10:03:41 UTC 2021
On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
> The bug occurs more often if initially the window is moved partly outside of the first screen(let's name this part as the invisible part), and then slowly moved to the second screen where that invisible part became visible on the second screen.
>
> The problem is how we try to repaint the frame. The Windows send us coordinates to repaint in the device space, if the width/height values are less than a unit in the user's space, we round it to the empty rectangle and skip it.
>
> Solution: request to repaint the smallest non-empty bounding box in the user's space around the region of pixels.
>
> Workaround: repaint the whole window on the component resize/move event or at the end of the drag.
>
> Notes:
> * It is not reproducible(at least much less often) when d3d is enabled because the d3d pipeline sends repaint events more often (example https://github.com/openjdk/jdk/pull/6064). That hides the current issue.
> * It started to be reproducible during the drag from one screen to another after JDK-8211999 because before JDK-8211999 we make a resize at the end of the drag, which caused the full repaint of the window.
Please correct my understanding. Does this refined repaint logic apply even for overlapping Windows? What happens when 2 windows are overlapping and we move top window slowly? Any performance/power impact?
-------------
PR: https://git.openjdk.java.net/jdk/pull/6339
More information about the client-libs-dev
mailing list