[BRLTTY] New release soon.

[Aura Kelloniemi]

Hi,

On 2024-10-08 at 14:39 -0400, Nicolas Pitre <nico at fluxnic.net> 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