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.
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 >> Gnome-accessibility-devel@gnome.org >> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel > > _______________________________________________ > Gnome-accessibility-devel mailing list > Gnome-accessibility-devel@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel _______________________________________________ Gnome-accessibility-devel mailing list Gnome-accessibility-devel@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
