Re: [orca-list] Chromium performance degraded after orca update

[Joanmarie Diggs <jdiggs igalia com>]

Hey Kyle.

Thanks! It surprises me that this particular change is the culprit. If
you switch back to master and see the performance problem, and then
revert just that one commit, does the problem go away?

If it does, then the problem may be related to the fact that at the
present time Orca is not using the AT-SPI2 cache for accessible parents
for Chromium. The reason why was/is a Chromium bug. And I just landed a
fix for it in Chromium today. Therefore my plan in a few days will be
to switch Orca back to using the AT-SPI2 cache for parents. That should
improve performance.

Thanks for all your help getting to the bottom of this problem!
--joanie

On Wed, 2020-10-07 at 12:15 -0400, Kyle via orca-list wrote:
> I think I found the commit that introduced my huge performance hit
> in 
> Chromium. I probably never saw it because I have been running an
> Orca 
> release since about March, and this would have shown up in master to
> be 
> released with 3.38.0 I think. The result of my bisect shows this:
>
>
> 972b22385a199df9a71fcbe1233bf6a7976ff81b is the first bad commit
> commit 972b22385a199df9a71fcbe1233bf6a7976ff81b
> Author: Joanmarie Diggs <jdiggs igalia com>
> Date:   Mon May 4 15:12:12 2020 -0400
>
>      Improve heuristic to identify elements serving as fake
> placeholder 
> for text
>
>      We want to treat fake placeholders for fake inputs like 
> placeholders and
>      not confuse them for editable content in a contenteditable. The 
> existing
>      heuristic was working for Firefox, but not for Chromium due to 
> extra divs
>      being included in the accessibility tree and also text leaf
> nodes being
>      incorrectly treated as editable text elements.
>
>   src/orca/scripts/web/script_utilities.py | 7 ++++---
>   1 file changed, 4 insertions(+), 3 deletions(-)
>
>
> This makes sense that it would affect Chromium and not Firefox, but 
> unfortunately it has a pretty nasty side effect, as it causes
> movement 
> to the bottom of a page and even movement up a line from the bottom
> to 
> take roughly 3 to 4 seconds, where before that it usually only took 
> about a second or less. Not sure there's much that can be done about
> it, 
> but there it is. Hope it helps.
>
> ~Kyle
>
> _______________________________________________
> orca-list mailing list
> orca-list gnome org
> https://mail.gnome.org/mailman/listinfo/orca-list
> Orca wiki: https://wiki.gnome.org/Projects/Orca
> Orca documentation: https://help.gnome.org/users/orca/stable/
> GNOME Universal Access guide: 
> https://help.gnome.org/users/gnome-help/stable/a11y.html