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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Mon Jun 4 20:57:33 UTC 2018


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.



More information about the swing-dev mailing list