On 8/24/2016 6:33 PM, Sergey Bylokhov wrote:
On 23.08.16 22:06, Semyon Sadetsky wrote:
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?
I'm not sure that "nothing is changed". The external visible size is not
changed but the internal state does. The internal state may include a
set of different areas sizes, vertical/horizontal scroll bars
visible/hidden.
But according to the spec of the listener it should be called only
when the view's size, position, or the viewport's extent size has
changed.
Based on logs the size and positions are the same, what else can cause
this notification called 6 time?
When scroll bars change visibility the extent size is changed and the
scrolled component is relayouted which changes the view size.
As I already mentioned it can cause several layout iterations depending
on the scroll policy, L&F, etc. So, once again, it is expected behavior,
and moreover it is unrelated to the current fix.
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
