On 23.08.16 20:57, Semyon Sadetsky wrote:
Just to clarify, on what L&f the bug is reproduced? Why we call the
listener 6 times when we set the size of scroll only once?
I tried to print the bounds of the viewport in the listener and it
seems that they are the same most of the time:
bounds = java.awt.Rectangle[x=2,y=2,width=15,height=46]
bounds = java.awt.Rectangle[x=2,y=2,width=15,height=46]
bounds = java.awt.Rectangle[x=2,y=2,width=0,height=46]
bounds = java.awt.Rectangle[x=2,y=2,width=0,height=46]
bounds = java.awt.Rectangle[x=2,y=2,width=0,height=46]
bounds = java.awt.Rectangle[x=2,y=2,width=0,height=46]
So probably it is possible to minimize the number of calls?
This is expected behavior. It is because JScrollPane consists of several
areas which may report changes each time they got a size.
But in some cases the size is the same, for example in the text above
notification occurred twice for [x=2,y=2,width=15,height=46].
This is how the internal JScrollPane layout algorithm works. It is most
optimal way to layout the viewport, the text inside it along with the
scroll bars. It requires several iterations usually.
Yes, we can validate/revalidate do some other stuff internally, but it
is unclear why we call the listener when actually nothing was changed
from the user point of view(bounds are the same). I see that in the code
we have some check to block such noop notifications, but probably in
some cases they are missed?
On 23.08.16 11:59, Alexander Scherbatiy wrote:
The fix looks good to me.
Thanks,
Alexandr.
On 23/08/16 11:40, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8163167
webrev: http://cr.openjdk.java.net/~ssadetsky/8163167/webrev.00/
The cause of this test bug is revalidating JScrollPane layout may
take
various number of iterations on different L&Fs.
To fix the test the counter listener is added after the layout
revalidation has been started.
--Semyon
--
Best regards, Sergey.
