Re: [g-a-devel] [Kde-accessibility] [Accessibility] a11y / D-Bus / lifecycle ...

[Michael Meeks <michael meeks novell com>]

Hi Eitan,

On Wed, 2007-12-19 at 10:51 +0200, Eitan Isaacson wrote:
> 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.

	:-) quite likely.

> stateset = acc.getState()
> visible = stateset.contains(STATE_VISIBLE)
> stateset.unref()

	Silly isn't it :-) of course; you can call 'getStates' on the state-set
if you want to know several states.

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

	Sure - and this cuts to the heart of the "lets standardise the IPC
interface" debate: basically, efficient IPC is almost always anathama to
usability & readability.

	The existing 'stateset' interface is highly readable, comprehensible,
"pleasant" when wrapped directly into a programming language, and
(unfortunately) also mind-bogglingly bad performance wise :-)

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

	Sure; this is a given though, even if you have a strong lifecycle
guarentee.

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

	Of course, the per-object filtering should happen at the bus level
there to reduce IPC - which is asking for some complicated filtering
logic.

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

	Great feedback,

	Thanks,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot