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

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

<Swing 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: <Swing Dev> <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: <Swing Dev> <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.

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

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

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

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

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

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

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

Alexandr Scherbatiy
In reply to this post by mikhail cherkasov

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

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

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

mikhail cherkasov
In reply to this post by Sergey Bylokhov
Hi Sergey, Alexander,

I have to revert the fix back to first version:
http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.03/
because invokeAndWait has side affect and needs to be called on all
components separately, otherwise runtime exceptions can be occurred.

Thanks,
Mikhail.


On 2/27/2017 8:13 PM, Sergey Bylokhov wrote:

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

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

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

Sergey Bylokhov
Looks fine.

> 28 февр. 2017 г., в 17:40, Mikhail Cherkasov <[hidden email]> написал(а):
>
> Hi Sergey, Alexander,
>
> I have to revert the fix back to first version: http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.03/
> because invokeAndWait has side affect and needs to be called on all components separately, otherwise runtime exceptions can be occurred.
>
> Thanks,
> Mikhail.
>
>
> On 2/27/2017 8:13 PM, Sergey Bylokhov wrote:
>> 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.
>

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

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

Alexandr Scherbatiy

The fix looks good to me.

Thanks,
Alexandr.

On 3/1/2017 9:20 PM, Sergey Bylokhov wrote:

> Looks fine.
>
>> 28 февр. 2017 г., в 17:40, Mikhail Cherkasov <[hidden email]> написал(а):
>>
>> Hi Sergey, Alexander,
>>
>> I have to revert the fix back to first version: http://cr.openjdk.java.net/~mcherkas/8171808/9/webrev.03/
>> because invokeAndWait has side affect and needs to be called on all components separately, otherwise runtime exceptions can be occurred.
>>
>> Thanks,
>> Mikhail.
>>
>>
>> On 2/27/2017 8:13 PM, Sergey Bylokhov wrote:
>>> 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.

Loading...