GNOME Bugzilla – Bug 529730
fast scrolling can lead to lag
Last modified: 2013-01-02 15:36:54 UTC
Please describe the problem: Some keys on a braille display are subject to key repeat, if the user enabled key repeat. With a small repeat delay, it can happen that while you scroll down a long page, say in Firefox, after you release the down key on your braille display, orca continues to scroll down further, because some keypress events have accumulated and have not been processed yet. Will suggests on IRC this might be because flat_review code might be to slow, which could be optimized to get rid of this anoying lag. Steps to reproduce: 1. In the BRLTTY preferences menu, enable "Autorepeat" and set "Autorepeat delay" to something like 20. 2. Open a page in firefox with a lot of text lines. 3. Scroll downward with your braille display, holding the down key pressed for a few seconds. 4. Release it, see how the scrolling continues? Actual results: BRLTTY sends the same command repeatedly if it detects the key is pressed down continues. The interval is defined by the autorepeat delay. If these events come in too fast, they pile up and orca is "lagging behind in time" so to speak, so it can not detect when exactly the user stopped to press that key. Expected results: Obviously, the scrolling should stop as soon as the key is released. Does this happen every time? It depends on available CPU power. Other information:
Mario, which speech engine are you using? Have you tried one besides eSpeak?
I see the behaviour reported in thsi bug report when using no speech engine at all (only braille output), which is my default way of working.
In the report, Firefox is specifically mentioned. Hopefully we'll see at least a partial improvement when we're only building up the context one time instead of three (i.e. bug 535178).
We'll chisel away at this one little by little, but I don't think we can do any aggressive performance fixes for the 2.24 cycle. For 2.26, we might try taking a look at removing existing events on the event queue that might cause us to perform redundant operations or operations that would just be interrupted anyway. For example, if there are a whole bunch of line down operations in sequence, we might try to avoid full processing and presentation of each line and instead just handle the intervening line down operations in a more limited fashion.
*** Bug 543734 has been marked as a duplicate of this bug. ***
Planning spam. Sorry!
Orca's overall performance as well as AT-SPI2's has been significantly improved and continues to be further improved now that accessibility is always enabled in GNOME. As new, specific, reproducible issues are found, new bugs should be opened.