GNOME Bugzilla – Bug 133385
Performance is slow when using GOK with 'File types and Programs' application
Last modified: 2004-12-22 21:47:04 UTC
Using GOK from CVS HEAD 2nd Feb 2004 -launch GOK -launch 'File types and Programs' Applications->Desktop Preferences->Advanced->File types and Programs -Notice GOK appears to freeze. After about 30-40 seconds, GOK comes alive again. Everytime you activate or click any feature on the application, GOK's performance is really slow. -Movement should be quick and smooth. running GOK on a machine : Intel Pentium 4 CPU 2.00GHz
Fixing this may not be practical: File Types and Programs is a very complex hierarchy. Note that at-poke's 'Expand' button takes the same amount of time to execute. One thing I notice is that File Types and Programs has lots of un-expanded items in the list; if GOK did not descend into lists that weren't expanded, we'd avoid the time penalty but we might well introduce new problems (since we'd then have to refresh our GUI hierarchy on every 'expanded' state change!).
I put a workaround for this in cvs (which was fairly straightforward), which eliminates the symptom in the case of this particular app. Padraig is looking at the gail implementation of that table to see if behavior is correct. We should probably file a separate bug for GOK's treatment of tables in general, since the current behavior is not sufficient for the general case. Also, though it should be a separate bug, I note that we cannot at present expand expandable table element via GOK.
Just out of curiosity, how does Gnopernicus flat review perform with this application? This would be a good test...
Peter: don't know the answer, but bear in mind a significant difference: gnopernicus flat review should use bounds checking of tables to determine the visible elements, whereas GOK doesn't require that actionable elements be visible in all cases. Probably a reasonable requirement in tables however, and the right long-term fix for GOK IMO (i.e. check for MANAGES_DESCENDANTS, if it's present and object is AccessibleTable, find out bounding row/col range for visibility and restrict the search to that area). However, that also means that GOK would have to rebuild its component list whenever visibility of a table changes (i.e. on scrolling), which could introduce some even more serious performance issues.
Bill - yes, I am aware of the difference between the design of Gnopernicus with respect to flat review, clipping, and tables. In fact, it is precisely because of this that I think this is an interesting test case, which is why I am suggesting that testing poke around in here with Gnopernicus. It will be interesting to see how well those algorythms work in this case.