[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


Reply to: