RFR: 8309460: JScrollBar leaves behind clutter for non-integer UI scales

[Alexey Ivanov]

On Tue, 23 Jan 2024 04:31:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Lines  are left behind when moving the scrollbar in the positive direction. but are cleaned up on mouse release. 
>> Additonally, with right arrow clicks too, the lines are left behind.
>> Seems like for mouseDragged and scrollByUnit, the dirty region of the scrollbar is not repainted leading to artifacts
>> which is being done in this fix..
>
> Looks to be related to 
> 8032219: [macosx] Scrollbars looks bad under retina 
> which changes the way scrollbar is drawn for Metal and Motif L&F by using fillRect instead of drawLine
> 
> and the current issue also happens for Metal and Motif L&F
> but not for say, Windows and Nimbus L&F

> @prsadhuk @aivanov-jdk I have a clarification regarding the proposed fix.
> 
> With the original solution the scrollbar repaint is done only when mouse is released or scrolled by a block, with the proposed fix the repaint is called continuously as long as the mouse is dragged or scrolled by a unit. Won't this result in a lot of calls to repaint and thus cause an overhead?

Additional repaints can create an additional overhead. On the other hand, repaint requests are coalesced. If the scrollbar wasn't repainted, you wouldn't see the thumb move, so there are repaints.

What I don't understand is why those repaints aren't enough and adding one more, apparently at the same location, solves the problem.

When you drag the thumb, to paint it in the new location, you need to paint the background over the old location and then the thumb in the new location. The suggested fix adds one more repaint of the rectangle where the scroll thumb is currently located. Or maybe not, and `getTrackBounds` returns the new rectangle by the time it's called in `scrollByUnit`.

The call to `scrollByUnits` one line above updates the location of the thumb, which changes the model and eventually should call repaint for the old position of the thumb and for the new position of the thumb. The dragging code could handle repaints in an optimised way though.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17484#issuecomment-1908910540