Bug 762769 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

In bug 1881195, I hypothesised that we might be able to get an early win and improve UIA performance by implementing IsControlElement, even though our UIA implementation is still based on IAccessibleEx. After that landed, I did the following test both with and without accessibility.uia.enable set to true:

1. Opened https://w3c.github.io/html-aam/ (pretty large document) in a new window.
2. Waited for it to finish loading.
3. Focused an element on the page.
4. Opened the NVDA Python Console with NVDA+control+z.
5. Ran the following code:
    `import time, UIAHandler as uh; e = uh.handler.clientObject.ElementFromHandle(nav.windowHandle); t = time.time(); e.FindFirst(uh.TreeScope_Descendants, uh.handler.clientObject.CreatePropertyCondition(uh.UIA_AutomationIdPropertyId, "foo")); time.time() - t`

UIA disabled: ~4.1sec
UIA enabled: ~3.1 sec

For comparison, Chrome (which has a native UIA implementation not based on IAccessibleEx) takes ~0.44sec.

So implementing IsControlElement in Firefox is a decent improvement, but things are still pretty slow.

Profile: https://share.firefox.dev/43a7aHe

That profile shows that UIA spends a lot of time in AccessibleObjectFromWindow (and the resultant calls to LresultFromObject and ObjectFromLresult, etc.) due to getting the fragment root to calculate the runtime id. That is really unfortunate because there's not really anything we can do to prevent or improve that while we're using the IAccessible proxy. That means the only path forward is a full native UIA implementation. :(
In bug 1881195, I hypothesised that we might be able to get an early win and improve UIA performance by implementing IsControlElement, even though our UIA implementation is still based on IAccessibleEx. After that landed, I did the following test both with and without accessibility.uia.enable set to true:

1. Opened https://w3c.github.io/html-aam/ (pretty large document) in a new window.
2. Waited for it to finish loading.
3. Focused an element on the page.
4. Opened the NVDA Python Console with NVDA+control+z.
5. Ran the following code:
    `import time, UIAHandler as uh; e = uh.handler.clientObject.ElementFromHandle(nav.windowHandle); t = time.time(); e.FindFirst(uh.TreeScope_Descendants, uh.handler.clientObject.CreatePropertyCondition(uh.UIA_AutomationIdPropertyId, "foo")); time.time() - t`

UIA disabled: ~4.1 sec
UIA enabled: ~3.1 sec (~1.3x faster)

For comparison, Chrome (which has a native UIA implementation not based on IAccessibleEx) takes ~0.44 sec (~9.3x faster than Firefox with UIA enabled).

So implementing IsControlElement in Firefox is a decent improvement, but things are still pretty slow.

Profile: https://share.firefox.dev/3PfTZ1F

That profile shows that UIA spends a lot of time in AccessibleObjectFromWindow (and the resultant calls to LresultFromObject and ObjectFromLresult, etc.) due to getting the fragment root to calculate the runtime id. That is really unfortunate because there's not really anything we can do to prevent or improve that while we're using the IAccessible proxy. That means the only path forward is a full native UIA implementation. :(

I do still see some calls to UIA's Acc2AttributeParser::GetAttributeValue, which does regex stuff, but I can't see what property triggered that. Still, that's taking significantly less time than AccessibleObjectFromWindow, so I'm not sure how much point there is in chasing this.

Back to Bug 762769 Comment 4