Re: [g-a-devel] Not so easy: About pyatspi2 deprecationg and the merge of ATK and AT-SPI

[Piñeiro <apinheiro igalia com>]

On 10/30/2013 11:08 PM, Magdalen Berns wrote:
> Hi Alejandro,
>
> Thanks for starting this thread. My two pence:
>
> > 1. Why can't we just deprecate pyatspi2 and start to use gobject
> > introspected bindings?
> >
> > As far as I know, pyatspi2 adds some wrapping over the pure
> > gobject-introspected calls. Some were done to fix some reentrancy
> > problems (although as far as I see those were moved to libatspi itself)
> > and other bugs. As mentioned yesterday, it is all about moving those
> > fixes to libatspi itself. In any case, there are some python-specific
> > wrapping, "utilities" like the emission of meaningful python exceptions,
> > that probably will be lost.
> Would you be able to provide a practical example of this?

About bugs that are solved thanks to have a manual wrapping:
https://bugzilla.gnome.org/show_bug.cgi?id=677070

But again, something that I always said. There are some uncertain on
this point. Some bugs are solving at the wrapping code, but I don't know
if it is a lot of code. Just saying that we shouldn't do the change
without knowing.

In any case, the big add-on on the manual wrapping are the utilities I
mentioned. This is also the bigger divergences on pyatspi2 API vs python
gobject introspected API. Some examples:

* Exceptions querying interfaces: pyatspi2 throw an exception if you
query for an interface but the object doesn't implement it. With python
gobject-introspected code, you will not have it. So current code:
  try:
    selection = accessible.queryComponent
  except NotImplementedError:
    <use a fallback to get the selected object>
  else:
    <get the selected object using the selection interface>


Would need to be replaced by
  selection = accessible.get_selection_iface()
  if (selection):
       <get the selected object using the selection interface> 
  else:
    <use a fallback to get the selected object>

* Registry.registerEventListeners allow to register more than one event
on one call.
* All the utility methods at utils.py
* etc

> > So as you can see both approaches has pros and cons. So the tricky
> > question: which use? On that specific example, in order to decide, we
> > would need to make some benchmarking, similar to this old one:
> > https://wiki.gnome.org/Accessibility/Documentation/GNOME2/ATSPI2-Investigation/IPCResults
> This is a great idea. In fact, I think a well devised experiment (or
> ten) should be able answer many of the FAQ questions. 
>
> One thing though, although those researching for the ATSPI2
> investigation were clearly very knowledgeable and their tests and write
> up seemed like a great framework to use, but it is important to note
> that there is a costly mistake (or at least it seems that way from
> skimming through) in there. 
>
> The study seems to have failed to consider/make note of sources of error
> which would not only tell us the precision of results obtained, but also
> probably explain why the final results so surprising to the author.

As far as I know, the only surprise that the author found, was that DBUS
was event slower than expected. But in any case, he was already waiting
DBUS being slower.

In any case, those tests are really old. I was not saying re-analyze
them, but doing similar tests with the current environment.

> > =========
> >
> > Reducing the amount of places to update each time the GNOME
> > accessibility spec changes makes sense, would be a good idea, and it is
> > worth investigate it. But taking into account all the still not answered
> > questions, the amount of work that would need, and all the priorities we
> > have right now (like Wayland), probably this is not the best moment to
> > focus on this.
> >
> > Comments, questions, doubts, feedback in general?
> Whatever gets decided between those who know about this problem, it is
> great you brought this up here! If any of the ATK/libspi experts are
> keen to construct experiments and need/want some assistance with
> experimental design and analysis side of things, then I have a
> reasonable level of skill and experience in that area and would be very
> happy to get involved, if it could be useful. For now, feel free to rip
> the following to shreds but I thought of a fairly loose/vague possible
> 'plan of action' could follow on nicely from your initiative to talk
> about the issue might be:

In an abstract way, what we would like to have is a test suite that
would allow us to measure any possible performance bottleneck on the
current environment. But not only to modify what we have, but also to
measure possible changes. For me, the more important is that we would
like this test suite to be easily repeated.

So in relation with the standard steps you list.

> 1. List agree on which specific questions can/should be answered by
> experiment
>
> --time passes--
Questions are basically time used on atspi calls (not only individually,
but as a whole).

> 2. Experimentalists get together and design appropriate tests in quest
> to answer questions from step 1.

What I would do is creating some tests that represents usual tasks from
an Orca user. Something like:
  test1: Using gnome-shell: launching apps, switching apps, overview,
removing/adding favourites from the dash
  test2: Writing, launch gedit, write text, change format, navigate
through menus,
  test3. etc

Not sure if we should do this tests manually, or using scripts. There
are advangates of using scripts, but could affect the results, and are
somewhat synthetic.

> 3. Experimentalists calculate & Analyse results

Well, I guess that ths is the tricky part. Ideally I would like the test
suite to output information about previous tests and really automatic.
Something like.
  test1:
    atspi calls: getRole xxx times called,  yyyy average time per call
                    getAccessibleName zzzz times called, bbbbb average
time per call
  etc

> --time passes--
>
> 4. Experimentalists present results to list for fresh discussion
>
> --time passes--

Probably the first time we run that, could lead to current bottlenecks.
But as I said, another reason if having something to try changes, to
avoid regressions on performance.
> 5. Developers decide on the change based on results
>
> --time passes--
>
> 6. Developers decide how best implement action from step 5.
>
> --time passes--
>
> 7. Actual codes get written to implement changes decided in 6.

This is not clear. As I said, one of the ideas of measuring, is testing
a possible change.

BR

-- 
----
Alejandro Piñeiro