it's _incredibly_ slow, so much so that most users might assume GOK
had hung.

I can look into this one soon.  Part of this will be pruning the GUI
tree search as Bill suggested somewhere else.  The trick is to not
overlook anything while doing so.  Also, the maximum depth (and
breadth) of the search can be changed.

I don't have an accessible staroffice set up.  Can someone test this
to see if this is still the case?  Anyone?
(Note this is not a June 9th feature rush)

With a StarOffice build from last week (and a Gnome2.2 nightly build),
I've seen this significant slowness with GOK.

Thanks Patrick, I probably won't be able to look into this until
sometime after the feature freeze (June 9th).

It would be nice to have a couple of specific cases to test and
(roughly) time on a particular machine.

I suggest that we change the current pruning settings from max depth
of 99 and width of 99 to something more manageable.

*** Bug 107475 has been marked as a duplicate of this bug. ***

I've added gconf keys (in gok head):
apps->gok->spy->gui_search_breadth
apps->gok->spy->gui_search_depth

Note you must do a make install and restart your gconfd, or log out
and back in.  GOK often needs to interrogate the active application or
window for certain gui elements.  These keys describe a maximum
breadth to search (at any node), and the maximum depth to search when
walking the gui tree.  It would be great if someone could tweak these
to find optimal values for StarOffice. 

*** Bug 112281 has been marked as a duplicate of this bug. ***

GOK with StarOffice is still terribly slow with a gnome-2.4 build from
11 August. Has this been looked at since?

Perhaps if the priority could be raised on this bug. It is making
testing of GOK and SO tedious.

Ideally, I should have accessible staroffice on my linux workstation.
 Can anyone hold my hand and point me to the right tarball?

The 1.1 RC2 build of OpenOffice.org contains most everything that was
released in StarOffice 7.

The linux version is available for download from:
http://www.openoffice.org/dev_docs/source/1.1rc2/#linux

FYI I'm running accessible soffice now, thanks to everyone who emailed
me (Padraig, Patrick...)

I've updated gok-spy.c in cvs with some work towards a fix for this
issue.  I think you should notice a visible improvement, but there is
still more I can do, bit it is a bit more involved and so I will want
to proceed carefully since we are so close to the release.

Please let me know if this is an improvement.

Just to add, the slowness is also apparent in other accessible java
appas like SwingSet2. I've just run gok with this app in a build from
the 14th August.

adding accessibility keyword

My work on this bug got sidetracked. I will treat this as top priority.

I am working on the related 117072.
Thinning the search depth and breadth doesn't really impact this bug,
since StarOffice does require significant depth/breadth searching.

Agreed.  There are some heuristics that have improved the search.  I
will help revisit this when we see the impact of the related bug's fix.  

Created attachment 21595 [details]
gok benchmarks

attached above is the results of the rough benchmarks carried out at
the beginning of October.

The current results are at least an order of magnitude too slow; and
if we expect StarOffice to be usable on a machine with less processing
power than 966 P6 (which we do), we'll need still more.  I'd venture
to say we need a factor of about 18.

I think 6 of that can be dealt with by the fix to 117072, but that
leaves a factor of three, which is pretty aggressive.  I am not sure
we can achieve this in GOK alone.

Sounds like we would need to store and update a model of the
application which is yucky IMO.

in the sense of a traditional offscreen model? no.

But clearly we do need to keep a list of 'interesting' UI items in the
current context.  I don't think we necessarily should keep such a list
on a per-application basis, however.

IOW we just need to update our list when the 'context' changes, i.e.
when toplevel window focus changes.  Thus we call the update function
once per window:activate call.  This combined with not calling
foo_has_child() multiple times (or at all), will get us a factor of 6
anyhow.

The remaining factor-of-three may be tougher.  I have a version of a
patch for this which I'm testing now (the gtk+ focus issue is making
it hard to test effectively ATM).  It's a pretty aggressive patch,
e.g. it rips out a lot of stuff and replaces it, but I think it'll
help a lot.  It's possible that we'll get more than 6x out of it.

The "rips out a lot of stuff" part makes me nervous...

yeah, I understand.
A lot of the stuff getting 'ripped out' appears to be cruft.  But this
work is requiring a fundamental rework of the UI search logic, thus
the relatively big impact. 

I think it's justified given the impact/size of the bug, i.e.
StarOffice being 2 orders of magnitude slower with GOK than we'd like.

This bug seems to have gotten much better as a result of the recent
changes for 117072: initial validation of GOK's Menus, UIGrab, and
Toolbar buttons takes under 1 second for a StarOffice document on my
(admittedly fast) x86 Suse machine (2.8 GHz), and display of the
appropriate GOK dynamic keyboard takes under one second.

Tempted to close this bug immediately, but probably we should do some
more testing.  Note also that I had to patch around a crasher bug to
test this, so that blocking bug needs to be fixed in order to get good
results with StarOffice and GOK from HEAD.  For now, am downgrading
the bug from 'Urgent' to 'High', pending more testing, with the hope
or marking it fixed.

confirmed that all above operations now take < 1 second on a 2.6 GHz
Linux x86 machine.  The branching operations that took longest in the
bug report (branch to ui grab, for instance) now all take only a
fraction of a second.  The only operation that takes a noticeable
amount of time is the initial validation of the three 'dynamic'
buttons on the GOK main keyboard, subsequent branching to them is
nearly instantaneous.

what's our minimum target machine?  Unless we target 500 MHz...it
looks as though all operations should be within our 2 second maximum
time on 1MHz and above.

David H, need feedback on this performance issue.

closing as fixed.  Reopen if serious problem (i.e. stopper magnitude)
is found to still exist, or open separate bugs for remaining issues.

using GOK with a StarOffice spreadsheet is still no fun.
The problem has reappeared, albeit less severely, since a change to
GOK logic which updates the component list on every keyboard branch.

We should really only update the component list in response to
"CONTAINER" add/delete events, and on application-context switches.

In order to fix this = we need to keep a more complete component list
(i.e. not use "current keyboard" flags when updating the master list),
and there may be some other small logic changes required.

Suggest fixing for gnome-2.6.1.

note: I still think it was right to close this bug previously, since
we are still an order of magnitude faster than we were before the
initial performance fixes.  Perhaps this should be a new bug?  

(opening a new bug).