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

[Mark Doffman <mark doffman codethink co uk>]

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
>>> 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
>