<Swing Dev> [11] Review Request: 8202768 [macos] Appkit thread slows when any Window Manager active

Anton Tarasov anton.tarasov at jetbrains.com
Sat Jun 9 14:20:43 UTC 2018


On 6/8/2018 11:38 PM, Sergey Bylokhov wrote:
> Hi, Anton.
>
> On 08/06/2018 07:57, Anton Tarasov wrote:
>> Is it possible that 'accessibilityAttributeNames' is called not from 
>> 'NSAccessibilityUnignoredAncestor'? In that case it will behave 
>> differently when the element is ignored. From the other hand, it's 
>> probably useless to return any attribute except 
>> 'NSAccessibilityParentAttribute' from an ignored element. In scope of 
>> that, does it make sense to return only 
>> 'NSAccessibilityParentAttribute' for an ignored element?
>
> Yes I think that most of the attributes are not necessary(not used) in 
> case of "ignored elements". But I do not know for sure which, except 
> "NSAccessibilityParentAttribute", should remain(like 
> NSAccessibilityRoleAttribute/NSAccessibilityHelpAttribute or maybe 
> children related attributes). So I decided to skip any additional 
> attributes which are not set by default, because default attributes 
> are cached and should not affect performance.

Ok, then. I'm fine with the fix.

Regards,
Anton.

>
>>
>> Regards,
>> Anton.
>>
>> On 6/4/2018 11:57 PM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review the fix for jdk11.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202768
>>> Webrev: http://cr.openjdk.java.net/~serb/8202768/webrev.00
>>>
>>> Short description:
>>> The root cause of the bug is tremendous complexity of code which 
>>> iterate over hierarchy of accessibility components, it was added 
>>> unintentionally in JDK-8145207:
>>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/233b59b7ea2f#l8.97
>>>
>>> Description:
>>> Our NSView component implements a accessibilityHitTest() method 
>>> which is part of accessibility api. When this method is called we 
>>> need to return the first meaningful  accessibility component: "For 
>>> example, when you place a button in a window, the system typically 
>>> creates a button cell inside a button control inside a container 
>>> view inside a window. Users, however, don’t care about the view 
>>> hierarchy details. They should only be told that there’s a button in 
>>> a window. "
>>>
>>> To iterate the accessibility components we use 
>>> NSAccessibilityUnignoredAncestor() method
>>> https://developer.apple.com/documentation/appkit/1531456-nsaccessibilityunignoredancestor?language=objc 
>>>
>>>
>>> which usually should work in this way:
>>>   1 Check is the component is ignored, if not then return it.
>>>   2 If the component is ignored, then request a 
>>> NSAccessibilityParentAttribute.
>>>   3 If NSAccessibilityParentAttribute is supported then repeat the 
>>> step1 for the parent. etc.
>>>
>>> But our implementation works in this way:
>>>   1 Check is the component is ignored, if not then return it.
>>>   2 If the component is ignored, then request a 
>>> NSAccessibilityParentAttribute.
>>>   3 Check that NSAccessibilityParentAttribute is supported. We 
>>> create a list of all supported attributes in 
>>> accessibilityAttributeNames() - method which was updated in the fix.
>>>   4 in the accessibilityAttributeNames() we need to access the 
>>> parent so we repeat the step 1 for the parent and its parent, and 
>>> its parent, etc.
>>>   5 We return back to the first iteration in 
>>> accessibilityAttributeNames()
>>>   6 We report that NSAccessibilityParentAttribute is supported(it 
>>> was requested at step3).
>>>   7 We return the NSAccessibilityParentAttribute requested at step2.
>>>   8 Repeat the step 1 until we will found unignored parent.
>>> (...) some intermediate steps were skipped.
>>>
>>>
>>> As you see at step4 we iterate hierarchy of accessibility 
>>> components, we do this for each component. So it is quite slow when 
>>> we have big hierarchy of ignored components.
>>>
>>> To block such iteration at step4 I have added a check that it is not 
>>> necessary to access the parent when we build the list of supported 
>>> attributes if the current component is "ignored".
>>>
>>> Note: The bug can be reproduced on macOS by the testcase when the 
>>> iSnap is active.
>>>
>>>
>>
>
>




More information about the swing-dev mailing list