On Tue, 23 Jan 2024 04:31:45 GMT, Prasanta Sadhukhan <[email protected]> 
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

Reply via email to