On Wed, 10 Nov 2021 18:45:12 GMT, Sergey Bylokhov <s...@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
