Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Lisandro Damián Nicanor Pérez Meyer]

Package: at-spi2-core
Version: 2.24.1-2
Severity: important

According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
huge negative performace impact on Qt, so it should not be enabled by
default. And, if I understand correctly, this is the current behavior.

Upstream suggested that maybe we should try to only set this variable if
the appropriate hardware is found. Do you have any ideas on how we could
achieve this?

[upstream]
<http://lists.qt-project.org/pipermail/development/2017-June/030148.html>

Trying to improve everyone's experience, Lisandro.

-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'testing'), (101, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.12.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages at-spi2-core depends on:
ii libatspi2.0-0 2.24.1-2
ii libc6 2.24-17
ii libdbus-1-3 1.11.16+really1.10.22-1
ii libglib2.0-0 2.53.6-1
ii libx11-6 2:1.6.4-3
ii libxtst6 2:1.2.3-1

at-spi2-core recommends no packages.

at-spi2-core suggests no packages.

-- no debconf information

[Sebastian Humenda]

Hi

Lisandro Damián Nicanor Pérez Meyer schrieb am 02.09.2017, 11:02 -0300:
>According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
>huge negative performace impact on Qt, so it should not be enabled by
>default. And, if I understand correctly, this is the current behavior.
>
>Upstream suggested that maybe we should try to only set this variable if
>the appropriate hardware is found. Do you have any ideas on how we could
>achieve this?

This is not a good idea, because not all screen reader users have dedicated
hardware. Users only using speech for navigation would be without Qt a11y.
Couldn't we detect whether a screen reader (Orca) is installed, or is this a
default on Desktop systems, these days?

Cheers
Sebastian

[Lisandro Damián Nicanor Pérez Meyer]

I'm really open to suggestions. at-spi2-core is being installed by default on
standard installations, so we are inflicting a huge performance drawback to
most of our users. On the other hand people needing a11y really need to get
this on as simple as possible.

I'm pretty sure that if all the interested parties try we can find a good
technical solution to this.

--
Confucius say: He who play in root, eventually kill tree.

Lisandro Damián Nicanor Pérez Meyer

http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[Alex ARNAUD]

Le 02/09/2017 à 16:28, Lisandro Damián Nicanor Pérez Meyer a écrit :
> I'm really open to suggestions. at-spi2-core is being installed by default on
> standard installations, so we are inflicting a huge performance drawback to
> most of our users. On the other hand people needing a11y really need to get
> this on as simple as possible.

Primary, could you explain why you tell us that? In which case you've
noticed issue? I'm running Debian 8.9 with QT accessibility enabled
without any performance issue.

> I'm pretty sure that if all the interested parties try we can find a good
> technical solution to this.

Indeed. I wait to reproduce and to understand your use-case before to
participate to a debate to figure out your issue.

Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

[Lisandro Damián Nicanor Pérez Meyer]

On 2 September 2017 at 12:11, Alex ARNAUD <alexa...@hypra.fr> wrote:
> Le 02/09/2017 à 16:28, Lisandro Damián Nicanor Pérez Meyer a écrit :
>>
>> I'm really open to suggestions. at-spi2-core is being installed by default
>> on
>> standard installations, so we are inflicting a huge performance drawback
>> to
>> most of our users. On the other hand people needing a11y really need to
>> get
>> this on as simple as possible.
>
>
> Primary, could you explain why you tell us that?

Because it's at-spi2-core the package which sets the variable.

> In which case you've
> noticed issue? I'm running Debian 8.9 with QT accessibility enabled without
> any performance issue.

Look at the upstream thread I linked in the first mail. Allan happens to be the
developer behind the relevant Qt code.

>> I'm pretty sure that if all the interested parties try we can find a good
>> technical solution to this.
>
>
> Indeed. I wait to reproduce and to understand your use-case before to
> participate to a debate to figure out your issue.

Basically: Qt issuing all the necessary messages for a11y in machines
not needing a11y makes a lot
of cpu power waste, whether you notice it or not.

So we have a huge user base wasting power for something they don't
need. I'm pretty sure we can find a way to
avoid that happen and at the same time letting people who need a11y
easily turn it on.

--

Lisandro Damián Nicanor Pérez Meyer

http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[Samuel Thibault]

Control: reassign -1 libqt5core5a
Control: retitle -1 Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, qt accessibility should not always send all messages

Hello,

Lisandro Damián Nicanor Pérez Meyer, on sam. 02 sept. 2017 11:02:15 -0300, wrote:
> According to [upstream] setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a
> huge negative performace impact on Qt,

Upstream said "big", not "huge" :)

> so it should not be enabled by default.

On the long run, it really should. Just hiding issues is not the way
forward :)

Also, note that if the performance is so bad, it means something *needs*
to be fixed, otherwise blind users will get the bad performance, and
nobody will be there to fix it, because nobody notices it except blind
users, who are left with little hope to fix it by themselves.

> Upstream suggested that maybe we should try to only set this variable if
> the appropriate hardware is found.

Sebastian Humenda, on sam. 02 sept. 2017 16:18:16 +0200, answered:

> This is not a good idea, because not all screen reader users have dedicated
> hardware. Users only using speech for navigation would be without Qt a11y.

Exactly.

> Couldn't we detect whether a screen reader (Orca) is installed, or is this a
> default on Desktop systems, these days?

It is a default, and that is on purpose.

Lisandro Damián Nicanor Pérez Meyer, on sam. 02 sept. 2017 11:28:51 -0300, wrote:
> On the other hand people needing a11y really need to get this on as
> simple as possible.

And that's precisely the issue.

If at-spi is not installed and enabled by default, it's a real pain to
make a system accessible with a screen reader: you first have to divine
which package should be installed, then enable accessibility in some
control panel, and log out / re login, so that at-spi gets started. That
just can not work. While having it enabled by default, ready to be
activated, it's just a matter of pressing e.g. ctrl-alt-s to start
speech. That's a *huge* difference for blind people. This is discussed
in more details in my talk at DC15.

https://summit.debconf.org/debconf15/meeting/290/thanks-for-maintaining-a-desktop-environment-but-is-it-accessible/

Lisandro Damián Nicanor Pérez Meyer, on sam. 02 sept. 2017 14:34:01 -0300, wrote:
> Basically: Qt issuing all the necessary messages for a11y in machines
> not needing a11y makes a lot of cpu power waste, whether you notice it
> or not.

Ok, so it seems Qt does not implement the optimization that Gtk did.
Normally Qt should only send events that were requested by a screen
reader.

See the notification part of

https://www.freedesktop.org/wiki/Accessibility/Walkthrough/

It'd be useful if you could contribute text for the Qt part, btw :)

Samuel

[Allan Sandfeld Jensen]

On Sonntag, 3. September 2017 18:15:15 CEST Samuel Thibault wrote:
> On the long run, it really should. Just hiding issues is not the way
> forward :)
>
> Also, note that if the performance is so bad, it means something *needs*
> to be fixed, otherwise blind users will get the bad performance, and
> nobody will be there to fix it, because nobody notices it except blind
> users, who are left with little hope to fix it by themselves.

It is not a issue or a bug. The performance impact comes from sending
everything the mouse hovers over to the accessibility framework (for instance
to be spoken aloud), when there is not any accessibility tools running.

You are deliberately crippling Qt to always send dbus events even when no one
is listening.

Note the performance impact is the same in all applications regardless of
framework. Running accessibility tools has a substantional performance cost on
mouse movements, but a mouse rendered or text scrolling at 60 fps is
completely pointless to blind people, but rather important to everybody else.

'Allan

[Samuel Thibault]

Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote:
> On Sonntag, 3. September 2017 18:15:15 CEST Samuel Thibault wrote:
> > On the long run, it really should. Just hiding issues is not the way
> > forward :)
> >
> > Also, note that if the performance is so bad, it means something *needs*
> > to be fixed, otherwise blind users will get the bad performance, and
> > nobody will be there to fix it, because nobody notices it except blind
> > users, who are left with little hope to fix it by themselves.
>
> It is not a issue or a bug. The performance impact comes from sending
> everything the mouse hovers over to the accessibility framework (for instance
> to be spoken aloud), when there is not any accessibility tools running.

Well, if just moving mouse over windows does send a flurry of events,
that's already a bug. There is no need to send all of that to a
screen reader, the user won't be able to grasp everything anyway, only
not-too-short hovers would be useful (the final destination of the
movement, basically). And that's particularly a problem if that makes
the interface slow: it's already difficult to use a computer when one
has to use a screen reader. If that makes the interface much slower,
that's even more difficult, so it is still a bug for that reason.

> You are deliberately crippling Qt to always send dbus events even when no one
> is listening.

That's Qt's fault for not taking care of EventListenerRegistered
signals to determine whether someone is listening.

> Note the performance impact is the same in all applications regardless of
> framework.

No. Gtk sends only basic events (application creation notification,
basically) when there is no screen reader.

> Running accessibility tools has a substantional performance cost on
> mouse movements, but a mouse rendered or text scrolling at 60 fps is
> completely pointless to blind people, but rather important to everybody else.

Sure, but fps is not the only consequence. Responsiveness of the
interface is also a consequence. If the performance is really hurt,
that's probably because there are too many messages, and so many
messages can't be useful for a screen reader either. We do have seen
screen readers overflowed with flurries of useless notifications.

Really, looking at the whole picture: there are tons of messages needed
to get all the tiny movements of the mouse, and render the 60fps. On the
other hand, the refresh rates of screen readers are *much* slower. So
the message bandwidth needed for it should be much lower. If that's not
the case, it means there is spurious information that should be dropped.

Samuel

[Samuel Thibault]

Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:19:31 +0200, wrote:

> On Sonntag, 3. September 2017 19:57:55 CEST Samuel Thibault wrote:
> > Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote:
> >
> > That's Qt's fault for not taking care of EventListenerRegistered
> > signals to determine whether someone is listening.
>

> So it is Qt's fault that is doing what you have told it to do? You have set
> the environment variable to ignore the absence of listeners. That is what
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON does.

Ah? That's not what I had gotten in my tests. I'll check again, then.

The question of flurry of events is still there, and does matter for
screen readers. Avoiding to expose the issue to users without a screen
reader is a bit hiding it under the carpet.

Samuel

[Samuel Thibault]

Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:31:58 +0200, wrote:
> Note, the case where I saw the largest performance impact was not moving
> the cursor, it was self-modifying web-content, it would send every text change
> in the active focus. [...]
> But it is what Chrome would send on macOS and Windows when a
> screen-reader is detected as active.

Uh. While it can be necessary to get such information. Getting every
text change is the kind of spurious event I'm referring to. It should
throttle the sends, to avoid the flurry that the screen reader won't be
able to render as speech or braille anyway, and just make sure that the
last version is sent.

Samuel

[Allan Sandfeld Jensen]

On Sonntag, 3. September 2017 19:57:55 CEST Samuel Thibault wrote:

> Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote:
>
> That's Qt's fault for not taking care of EventListenerRegistered
> signals to determine whether someone is listening.
>

So it is Qt's fault that is doing what you have told it to do? You have set
the environment variable to ignore the absence of listeners. That is what

QT_LINUX_ACCESSIBILITY_ALWAYS_ON does. It is an override for embedded
applications which need to send accesibility events but for some reason can't
autodetect the presence of a listener.

> > Note the performance impact is the same in all applications regardless of
> > framework.
>
> No. Gtk sends only basic events (application creation notification,
> basically) when there is no screen reader.
>

So does Qt by default, but you are forcing a special override around that.

'Allan

[Allan Sandfeld Jensen]

True. Note, the case where I saw the largest performance impact was not moving

the cursor, it was self-modifying web-content, it would send every text change

in the active focus. The events came from Chromium, which is used in
QtWebEngine, but it is not code I have written, just Chromiums default
accesibility implementation. We have already worked around it in 5.9.2, as it
was almost useless and already disabled in the standard linux builds of
Chromium (probably because of the how badly it behaves), and firefox didn't
send similar events either on Linux. But it is what Chrome would send on macOS

and Windows when a screen-reader is detected as active.

'Allan

[Samuel Thibault]

Samuel Thibault, on dim. 03 sept. 2017 20:23:30 +0200, wrote:
> Allan Sandfeld Jensen, on dim. 03 sept. 2017 20:19:31 +0200, wrote:
> > On Sonntag, 3. September 2017 19:57:55 CEST Samuel Thibault wrote:
> > > Allan Sandfeld Jensen, on dim. 03 sept. 2017 19:13:38 +0200, wrote:
> > >
> > > That's Qt's fault for not taking care of EventListenerRegistered
> > > signals to determine whether someone is listening.
> >
> > So it is Qt's fault that is doing what you have told it to do? You have set
> > the environment variable to ignore the absence of listeners. That is what
> > QT_LINUX_ACCESSIBILITY_ALWAYS_ON does.
>
> Ah? That's not what I had gotten in my tests. I'll check again, then.

I have checked with a vanilla reinstall of Debian 9, using the Mate
desktop, and Qt 5.7.1.

When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt
applications in accerciser, only the Mate applications. If I set
QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them.

On my current desktop, I have Qt 5.9.1, I made quick tests, it seems
it behaves as I expect, so perhaps we can indeed avoid setting
QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla
reinstall of debian testing, to be sure.

Samuel

[Samuel Thibault]

Samuel Thibault, on dim. 03 sept. 2017 21:17:12 +0200, wrote:
> I have checked with a vanilla reinstall of Debian 9, using the Mate
> desktop, and Qt 5.7.1.
>
> When QT_LINUX_ACCESSIBILITY_ALWAYS_ON is not set, I don't see Qt
> applications in accerciser, only the Mate applications. If I set
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON, I do see them.
>
> On my current desktop, I have Qt 5.9.1, I made quick tests, it seems
> it behaves as I expect, so perhaps we can indeed avoid setting
> QT_LINUX_ACCESSIBILITY_ALWAYS_ON now. I'll retest with a vanilla
> reinstall of debian testing, to be sure.

Yes, a vanilla reinstall behaves as expected. So we can drop that
variable, good :)

Samuel

[Samuel Thibault]

Control: clone -1 -2
Control: reassign -2 at-spi2-core
Control: retitle -2 Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any more
Control: found -1 5.7.1+dfsg-3+b1
Control: done -1 5.9.1+dfsg-9

Samuel

[Samuel Thibault]

Lisandro Damián Nicanor Pérez Meyer, on dim. 03 sept. 2017 19:08:38 -0300, wrote:
> So you mean that something changed between 5.7 and 5.9?

It seems so.

Samuel

[Lisandro Damián Nicanor Pérez Meyer]

So you mean that something changed between 5.7 and 5.9? In that case I should try to track the necessary changes and try to backport them.

Thank you all for jumping in!

[Samuel Thibault]

Hello,

It seems my mails don't reach the devel...@qt-project.org mailing
list. Could somebody who got them forward them to it?

Frederik Gladhorn, on mar. 05 sept. 2017 10:32:43 +0200, wrote:
> And then Allan is right, by setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON you ask
> for it. All the stuff unconditionally. Please don't, why do you need it in the
> first place?

Because it would just not work at all in non-kde desktops in Debian 9
otherwise (and I didn't notice performance regression). AIUI, qt 5.7 was
only looking at the "accessibility enabled" checkbox in kde
configuration.

> Right now Qt is trying to emulate Gnome's way, except since we don't
> listen to the change signal, we never dynamically enable/disable a11y.

With Debian testing (qt 5.9), I don't need to set
QT_LINUX_ACCESSIBILITY_ALWAYS_ON, and accessibility seems to get enabled
dynamically, so it seems something changed between 5.7 and 5.9.

Samuel