I had some further thoughts regarding performance. I think the benefit
of a d-bus re-implementation at this point is that we could learn from
our current ATs, for example, I am convinced that at least %50 of Orca's
remote calls are redundant.
==Remote Objects==
First off there are some hot spots in the current AT-SPI design. For
example, StateSets. When you want to determine if an accessible object
say, is visible, you need to do the following:
stateset = acc.getState()
visible = stateset.contains(STATE_VISIBLE)
stateset.unref()
That is 3 round trips just to determine an accessible's state.
It could probably be reduced to one if getState() just returned a list
of primitives. Maybe there is another reason why this is set up this
way? If this is really necessary, at least it would be cool if the
remote StateSet object we use would stay valid, but it doesn't, if the
state changes, you need to retrieve a new stateset.
There are other remote objects that need to be also re-evaluated, like
Relation and BoundingBox.
==Lifecycle==
I know very little about the costs of different lifecycle schemes. But
if we are to use caching effectively on the AT side, we need to know
when a remote object went away in a reliable fashion, that needs to be
more than listening for a state-change. If an application crashes we
need to know to invalidate all cache items that are related to that
application. The better and more reliable our picture on the AT is, the
less we need to poll over the wire.
==Per-object events==
Today we listen for events in a global fashion from the registry, and
this is probably an ideal design from a screen reader perspective. But
sometimes we only want to know, for example, when a specific
accessible's state changes. So it would be cool if we could connect
callbacks GObject style, so we wouldn't receive events from the entire
desktop, just from that accessible. I think this could reduce the amount
of events some ATs receive dramatically. For example, in Orca, we listen
for a very high-traffic event called "object:children-changed:remove",
but we are only interested in it when the event source is the desktop.
Not sure what the implementation hardships of all that would be, but
those are just a couple of things that would allow AT devs to go over
the wire less often.
My 2c,
Eitan.
On Tue, 2007-12-18 at 17:43 +0000, Bill Haneman wrote:
> Michael Meeks wrote:
> > On Tue, 2007-12-18 at 15:55 +0800, Li Yuan wrote:
> >
> >>> Quite - me neither ;-) OTOH, it's a hard issue to fix: and
> >>> precedent-wise, MSAA, IAcc2, UIA, UNO a11y and atk use reference
> >>> counting :-)
> >>>
> >> Not sure if I understand this correctly. You are talking about the
> >> possibility for object lifecycle management in D-Bus, right? Then could
> >> we implement the Bonobo_Unknown interface in at-spi to handle the
> >> lifecycle problem?
> >>
> >
> > Yes; easily - but explicit lifecycle management is a total nightmare
> > for performance, efficiency, etc.
> >
> >
> Hi Li, Michael; :-)
>
> I agree with Michael here, if we can figure out a way to get rid of the
> cross-process lifecycle management (maybe client-side stubs that 'die'
> gracefully, or something similar?) then it would be a good thing.
> Perhaps the current changes are the right time to introduce such a
> change, since other behavioral things would be sure to change too.
>
> Bill
>
> > Regards,
> >
> > Michael.
> >
> >
>
> _______________________________________________
> 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
