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

[Sergey Bylokhov]

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.

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


-- 
Best regards, Sergey.