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

[Frederik Gladhorn]

I'm a bit split here, let's try to find some middle ground :)

I do think that we should always run with accessibility enabled and we don't 
do that for a reason.
One thing to fix for linux accessibility is listening to the change signal on 
for a11y being enabled or not. If I recall correctly listening to property 
changes on dbus is not implemented in Qt since it's impossible to know if 
there are any listeners to these change signals, Thiago knows the details I 
think.

The next thing is to make sure we don't actually send the keyboard and mouse 
events when not needed (pure insanity anyway, we should have a sound 
approach...). For the time being sending all of these events over dbus is the 
only way to make Orca happy and thus the only way to make applications behave 
somewhat acceptable for blind users. Thinking about the code gives me 
nightmares though and I'd support anyone looking at it and making sure we 
don't overdo the sending of events.

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?
Maybe it's time to sit down and create a somewhat defined way when it should be 
enabled? 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. The 
code is there, it's just actually reacting to the notification that's missing.

Cheers,
Frederik



On søndag 3. september 2017 19.13.38 CEST Allan Sandfeld Jensen 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.
> 
> 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
> ___
> Development mailing list
> developm...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

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

[Samuel Thibault]

Hello,

It seems my mails don't reach the developm...@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

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

[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

Re: 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]

El 3 sep. 2017 4:39 p.m., "Samuel Thibault"  escribió:

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


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!

Processed (with 1 error): Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #874054 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Bug 874054 cloned as bug 874174
> reassign -2 at-spi2-core
Bug #874174 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Bug reassigned from package 'libqt5core5a' to 'at-spi2-core'.
No longer marked as found in versions qtbase-opensource-src/5.7.1+dfsg-3.
Ignoring request to alter fixed versions of bug #874174 to the same values 
previously set
> retitle -2 Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any more
Bug #874174 [at-spi2-core] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Changed Bug title to 'Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any 
more' from 'Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative 
performance impact, qt accessibility should not always send all messages'.
> found -1 5.7.1+dfsg-3+b1
Bug #874054 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Ignoring request to alter found versions of bug #874054 to the same values 
previously set
> done -1 5.9.1+dfsg-9
Unknown command or malformed arguments to command.


-- 
874054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874054
874174: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874174
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed (with 1 error): Re: Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Debian Bug Tracking System]

Processing control commands:

> clone -1 -2
Bug #874054 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Bug 874054 cloned as bug 874172
> reassign -2 at-spi2-core
Bug #874172 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Bug reassigned from package 'libqt5core5a' to 'at-spi2-core'.
Ignoring request to alter found versions of bug #874172 to the same values 
previously set
Ignoring request to alter fixed versions of bug #874172 to the same values 
previously set
> retitle -2 Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any more
Bug #874172 [at-spi2-core] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Changed Bug title to 'Should not set QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 any 
more' from 'Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative 
performance impact, qt accessibility should not always send all messages'.
> found -1 5.7.1+dfsg-3+b1
Bug #874054 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, qt accessibility should not always send all 
messages
Marked as found in versions qtbase-opensource-src/5.7.1+dfsg-3.
> done -1 5.9.1+dfsg-9
Unknown command or malformed arguments to command.


-- 
874054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874054
874172: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874172
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[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

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

[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

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

[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

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

[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

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

[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

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

[Allan Sandfeld Jensen]

On Sonntag, 3. September 2017 20:23:30 CEST Samuel Thibault 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.
> 
> 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.
> 
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

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

[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

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

[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

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

[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

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

[Debian Bug Tracking System]

Processing control commands:

> reassign -1 libqt5core5a
Bug #874054 [at-spi2-core] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, should not be always on
Bug reassigned from package 'at-spi2-core' to 'libqt5core5a'.
No longer marked as found in versions at-spi2-core/2.22.0-6 and 
at-spi2-core/2.24.1-2.
Ignoring request to alter fixed versions of bug #874054 to the same values 
previously set
> retitle -1 Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative 
> performance impact, qt accessibility should not always send all messages
Bug #874054 [libqt5core5a] Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a 
huge negative performance impact, should not be always on
Changed Bug title to 'Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge 
negative performance impact, qt accessibility should not always send all 
messages' from 'Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative 
performance impact, should not be always on'.

-- 
874054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874054
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

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

[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

Re: 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]

On 2 September 2017 at 12:11, Alex ARNAUD  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/

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

[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"

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

[Debian Bug Tracking System]

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 Debian Accessibility Team 

If you wish to submit further information on this problem, please
send it to 874...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.

-- 
874054: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=874054
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: 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]

On sábado, 2 de septiembre de 2017 16:18:16 -03 Sebastian Humenda wrote:
> 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?

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/


signature.asc
Description: This is a digitally signed message part.

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]


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