Re: [Development] 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!
___
Development mailing list
Development@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

[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

___
Development mailing list
Development@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

[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
___
Development mailing list
Development@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

[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
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Backporting the Keccak change

[Harri Porten]

On Sat, 2 Sep 2017, Oswald Buddenhagen wrote:


if we wanted to be really conservative, we'd leave the old meaning of
the sha3 constants and introduce realSha3 (or something to that effect)
instead, in 5.10+. keccak aliases would be also provided for a smooth
migration.


Fwiw, I would have appreciated such a bug-compatible approach. For a new 
product we relied on the old SHA-3 to store hashes of data. That data is 
lost now. Luckily the losses were minimal and did not affect customers, 
yet.


On the other hand: having users rely on a buggy implementation without 
knowing (who reads API documentation for completed code?) has its 
downsides as well.


In that light, giving up the backward compatibility and changinging the 
Sha3_256 enum to intentionally breaking Sha3_256_Good+Sha3_256_Broken for 
the rest of Qt 5.x lifetime could have been an option, too


Harri.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development