Re: [Development] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on
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
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
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
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
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