The fix looks good to me.
The second version also contains the extra semicolon on the line 4542.
Thanks,
Alexandr.
On 2/27/2017 5:07 PM, Mikhail Cherkasov wrote:
Hi again,
with this implementation I see a runtime exception, I see it in
AccessBridge. getAccessibleNameFromContext.
InvocationUtils.invokeAndWait can't obtain AppContext. I don't see how
it relates to my changes, but without
my changes it works fine, also it works fine with first version of the
fix.
Thanks,
Mikhail.
On 2/27/2017 3:49 PM, Mikhail Cherkasov wrote:
Hi Sergey,
http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.02/
I wrapped the very fist invocations of _getVisibleChildrenCount and
_getVisibleChild into InvocationUtils.invokeAndWait
and removed all InvocationUtils.invokeAndWait inside those two methods.
Thanks,
Mikhail.
On 2/24/2017 1:08 AM, Sergey Bylokhov wrote:
Hi, Mikhail
Why we call invokeAndWait() so many times in the new method?
I guess we can do some work on EDT in one step then we will speedup
the code when the size of the table is huge and it has lots of
visible items.
Hi all,
Could you please review the fix:
http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.01/
for the following issue:
https://bugs.openjdk.java.net/browse/JDK-8171808
When JAWS asks java how many visible elements in the frame are,
java goes through the whole tree of component and asks each whether
it visible or not.
During this java creates accessContext for each element, so this
requires to get data from model.
So if user uses lazy loading or model is large, this counting makes
app to freeze.
I reduced the number of components that should be checked for
visibility,
if we get to a row that is invisible, there's no sense to check
next rows, the same for columns.
Thanks,
Mikhail.
