Hi David, > Right, accessible hierarchies change, sometimes a lot (e.g. DOM under > DHTML apps). I too, would be concerned about pushing all changes and the > potential for performance strain. I'm interested to hear more details > though.
I don't want to argue about this too much, because either way we'll have to do profiling to make sure. There are a couple of reasons why I don't think this won't be much of a strain. 1 - One large asynchronous call only has one context switch. Transferring data between processes in one push is pretty speedy. 2 - There isn't actually that much data. Remove all the images and from a web-page and you could quite happily push most of them in their entirety to ATs without much problem. Thanks Mark > > cheers, > David > > Willie Walker wrote: >> Hi Mark: >> >> The following is going to sound wishy-washy. The main thing is that >> I'm on the fence about this and think we really need a good >> performance analysis to determine which way to go. I'm CC'ing Michael >> Meeks for a number of reasons and hope he can also provide some insight. >> >>> What we have been doing with AT-SPI D-Bus doesn't fit well with this >>> system. The idea was that an application would 'publish' its >>> accessibility information to the ATs, by pushing an entire tree of >>> accessible objects at application start-up. >> Keep in mind that not every AT needs to know the complete hierarchy. >> Orca right now, for example, tends only to look at localized areas >> (e.g., the object with focus). With this, the notion in Orca was to >> treat the application itself as an off screen model rather than >> creating one locally. >> >> I think one of the motivations for lazy creation is dealing with very >> large hierarchies: opening a large OOo document, going to a URL with >> tons of content, opening a spreadsheet in OOo, etc. The thought is >> that it is more efficient to only create/use what you need. In >> addition, I recall some things (OOo?) may not create accessible peers >> for objects until they are rendered on the screen. For example, the >> accessible peers for text on page 666 of a very large document might >> be not created until the user navigates to that page. >> >> The very large hierarchy thing, however, is in fact one of the things >> that raises itself frequently on the Orca user list. For example, a >> lot of our sluggishness in Orca happens when people are trying to >> access content on very large pages in FF. Having the complete >> hierarchy locally would indeed help with this on the Orca side (Joanie >> is experimenting now), but we add the bookkeeping of dealing with >> changes to the hierarchy. Note that some of the performance hit we're >> taking is due to the fact that Orca needs to provide it's own >> caret/structural navigation for Firefox because the Firefox navigation >> code needs a lot of work: >> https://bugzilla.mozilla.org/show_bug.cgi?id=241023. Note also that >> in order for Orca to be able to do things such as more sophisticated >> navigation (e.g., "go to the next table in this document"), it needs >> access to the whole document. >> >>> What I'm asking for is that ATK, in the future, moves to a non-lazy, >>> push based system. This would mean removing laziness, so in the case of >>> GTK a GailObject would be created with the GtkWidget itself, rather than >>> only when requested. It would also mean providing a signal to indicate a >>> new AtkObject has been created. >> As you mention, this would impact more than just GTK+. It's been a >> long time since I've worked on the internals of Java/Swing, but I >> believe I recall I made the implementation there be lazy as well. >> That is, I don't believe the Accessible peer for it is created until >> one asks for it: >> http://java.sun.com/j2se/1.5.0/docs/api/javax/swing/JComponent.html#getAccessibleContext() >> >> >> Another thing to consider are objects that have the "manages >> descendants" property. They can end up having a HUGE number of >> children, which are perhaps not even known until one scrolls to them. >> As such, creating accessible peers for the children of object that >> manage their descendants may be impossible. >> >> In any case, I think the best thing to do here is experiment and get >> performance numbers, especially for very large hierarchies. >> >> Thanks for your work! >> >> Will >> >>> The Qt QAccessible interface works in exactly this way, and it makes for >>> a much simpler adaptor to AT-SPI D-Bus. >>> >>> I'm unsure why Gtk chose the 'lazy' route of object creation. I imagine >>> its an optimization for memory usage. I'm not sure its a good one >>> though, as GailObjects, once created, have their lifetime tied to their >>> implementing GtkWidget. This should mean that once an AT has searched >>> the Applications accessible objects most of the GailObjects have been >>> created anyway. >>> >>> In a more abstract way I think the 'push' model is conceptually better. >>> Say we were to use the GtkWidget 'realize' signal to delcare that a new >>> AtkObject has been created. In this case the GtkWidget is 'published' to >>> the AT at the same time that it starts using screen resources. >>> >>> This isn't a particularly large change. The addition of a 'created' or >>> 'new' signal to Atk doesn't make much difference to the API. The >>> difficulty is that all Atk implementations will have to be modified to >>> emit the signal, and that implementations that lazily create accessible >>> objects will have to change their behavior. >>> >>> I'm a fan of having accessibility turned on-by-default in Gnome, so I >>> don't have the excuse that this will only use extra resources when >>> accessibility is switched on. This change will use more memory for Gtk >>> applications. I'd need to do some investigation to find out how much. >>> >>> I'm not sure what the correct implementation in Gtk is, but its probably >>> as simple as adding gtk_widget_get_accessible somewhere in the GtkWidget >>> construction. Gail would have to be modified to emit the new signal >>> whenever a new GailObject is created. I don't know what the other Atk >>> implementations do with regards to lazily creating their Accessibility >>> implementation. I really doubt that the Mozilla or Java implementations >>> do it like Gtk, so modifying those might be much less politically >>> volatile, as no extra memory will be used. >>> >>> Thanks >>> >>> Mark >>> _______________________________________________ >>> Gnome-accessibility-devel mailing list >>> [email protected] >>> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel >> _______________________________________________ >> Gnome-accessibility-devel mailing list >> [email protected] >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > _______________________________________________ Gnome-accessibility-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
