Re: [g-a-devel] ATK - Signal indicating new AtkObject creation.

[Willie Walker <William Walker Sun COM>]

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