<Swing Dev> <AWT Dev> [9] Review request for 8171808: Performance problems in dialogs with large tables when JAB activated

[Mikhail Cherkasov]

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.
>