The fix looks good to me.
Thanks,
Alexandr.
On 10/14/2016 8:52 PM, Sergey Bylokhov wrote:
On 03.10.16 12:35, Semyon Sadetsky wrote:
But if layout was done, why we get any notifications? Should the check
be (cnt != 0)?
Okay. I have changed it to zero:
On 03.10.16 12:35, Semyon Sadetsky wrote:
But if layout was done, why we get any notifications? Should the check
be (cnt != 0)?
Okay. I have changed it to zero:
http://cr.openjdk.java.net/~ssadetsky/8163167/webrev.01/
Looks fine.
I assume that each notification should be called when the
On 9/30/2016 5:53 PM, Sergey Bylokhov wrote:
On 01.09.16 16:38, Semyon Sadetsky wrote:
If the test is correct why you tries to change it? The test found a
bug when we get more notifications than expected.
The issue was to count normal notifications from revalidation. Now the
counter starts
On 01.09.16 16:38, Semyon Sadetsky wrote:
If the test is correct why you tries to change it? The test found a
bug when we get more notifications than expected.
The issue was to count normal notifications from revalidation. Now the
counter starts to count after the layout is done.
But if
On 31.08.2016 21:01, Sergey Bylokhov wrote:
On 31.08.16 15:48, Semyon Sadetsky wrote:
As I already mentioned it can cause several layout iterations
depending
on the scroll policy, L, etc. So, once again, it is expected
behavior,
and moreover it is unrelated to the current fix.
The bug is
On 31.08.16 15:48, Semyon Sadetsky wrote:
As I already mentioned it can cause several layout iterations depending
on the scroll policy, L, etc. So, once again, it is expected behavior,
and moreover it is unrelated to the current fix.
The bug is that we call notification more time than
On 29.08.2016 15:24, Sergey Bylokhov wrote:
On 24.08.16 19:20, Semyon Sadetsky wrote:
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
On 24.08.16 19:20, Semyon Sadetsky wrote:
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.
The size of the
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
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
On 8/23/2016 9:29 PM, Sergey Bylokhov wrote:
On 23.08.16 20:57, Semyon Sadetsky wrote:
Just to clarify, on what L 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
On 23.08.16 20:57, Semyon Sadetsky wrote:
Just to clarify, on what L 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 =
On 8/23/2016 8:35 PM, Sergey Bylokhov wrote:
On 23.08.16 20:29, Semyon Sadetsky wrote:
On 8/23/2016 8:00 PM, Sergey Bylokhov wrote:
Just to clarify, on what L 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
On 23.08.16 20:29, Semyon Sadetsky wrote:
On 8/23/2016 8:00 PM, Sergey Bylokhov wrote:
Just to clarify, on what L 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
On 8/23/2016 8:00 PM, Sergey Bylokhov wrote:
Just to clarify, on what L 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 =
Just to clarify, on what L 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]
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
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
To fix the test the
18 matches
Mail list logo
