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

[David Bolter <dtb gnome org>]

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