Re: 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
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
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
Bug#840478: ksmserver: autostart service "/usr/bin/conky" finished with exit code 0
¡hola, max! I think the busted .desktop file happened when I tried to attach the same file to reportbug twice; the .desktop file itself is fine. But - still no joy. Since you were able to get yours to autostart I'm going to assume that the issue is on my end and most likely in my conky config as it's a little complex; I've tried not daemonizing, starting conky in the background and starting it with no command line options - mine just refuses to start although krunner or a terminal session will start it just fine. Please feel free to close this bug - and many thanks. allan
Bug#840478: ksmserver: autostart service "/usr/bin/conky" finished with exit code 0
Package: kde-baseapps-bin Version: 4:16.08.0-1 Severity: important * What led up to the situation? Upgraded Debian Unstable today. * What exactly did you do (or not do) that was effective (or ineffective)? Rebooted machine and started KDE as normal. conky refused to start and .xsession-errors gave the error above. Starting conky in a terminal window or with krunner works, it just won't autostart. * What was the outcome of this action? As mentioned, conky exits. * What outcome did you expect instead? Expected conky to autostart. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.7.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kde-baseapps-bin depends on: ii kde-baseapps-data 4:16.08.0-1 ii kde-runtime4:16.08.0-1 ii libc6 2.24-3 ii libkdecore54:4.14.23-1 ii libkdeui5 4:4.14.23-1 ii libkfile4 4:4.14.23-1 ii libkio54:4.14.23-1 ii libkparts4 4:4.14.23-1 ii libqt4-dbus4:4.8.7+dfsg-9 ii libqt4-xml 4:4.8.7+dfsg-9 ii libqtcore4 4:4.8.7+dfsg-9 ii libqtgui4 4:4.8.7+dfsg-9 ii libstdc++6 6.2.0-6 ii libx11-6 2:1.6.3-1 kde-baseapps-bin recommends no packages. kde-baseapps-bin suggests no packages. -- no debconf information *** /home/wizard/.config/autostart/conky.desktop [Desktop Entry] Exec=/usr/bin/conky -d Icon=system-run Path= [Desktop Entry] Exec=/usr/bin/conky -d Icon=system-run Path= Terminal=false Type=Application
Bug#320348: akode: dependency package libjack0.80.0-0 removed from repository
Actually the jack-sink and polyp-sink plugins should be packaged separately. They are plugins exactly for this purpose. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280974: mpeglib: Old bug #245192 never got fixed.
You can obsolete mpeglib. For MP3 and Ogg Vorbis decoding akode has superceded it, and for MPEG-1 decoding xine-artsplugin has superceded it. Bugs for mpeglib are likely to be closed as WONTFIX or INVALID now. `Allan
