Ok, Looks fine.
>
> 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.
>>
>
