Hi, On 2024-10-08 at 14:39 -0400, Nicolas Pitre <[email protected]> wrote: > I'd say that you might want a screen update to be reflected as quickly > as possible. However, if a subsequent update occurs within this > quiescent period then the update is delayed. This way, occasional > updates are always reported on the display with minimal latency, and a > rush of updates would be tamed.
Maybe, but that would defeat my second point of reducing effects of temporary cursor movements. > Well... the tracking wait value is unrelated to screen updates. Yes, I know. But increasing the update scheduling delay has a side effect. If there are many consecutive updates (which almsot always also move the cursor) only the latest one (during the specified delay interval) has an effect on BRLTTY's rendering. This results in some of the cursor movements to be disregarded as well. Turns out that in most scenarios applications update their display in less than 75 milliseconds, but many applications take more than 15 milliseconds to do a refresh. As a result, I very seldom get spurious cursor tracking even though I have disabled "cursor tracking delay". There are exceptions, like top, whose rendering is especially slow and I need to disable cursor tracking when using it. Of course I could ask for new value options to be added to the "Cursor tracking delay" preference, and maybe they would be very useful for some people. Personally I have resolved the situation by increasing the update scheduling delay for now. I'm not arguing that the solution would be good for anybody else, just that I have used this trick for several years and have been happy with it. -- Aura _______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
