Re: [g-a-devel] ATK - Signal indicating new AtkObject creation.
- From: Willie Walker <William Walker Sun COM>
- To: Mark Doffman <mark doffman codethink co uk>
- Cc: gnome-accessibility-devel gnome org, Michael Meeks <michael meeks novell com>
- Subject: Re: [g-a-devel] ATK - Signal indicating new AtkObject creation.
- Date: Tue, 13 Jan 2009 09:40:27 -0500
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]