Quantcast

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

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

mikhail cherkasov
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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

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

Loading...