[BRLTTY] New release soon.

[Nicolas Pitre]

On Tue, 8 Oct 2024, Aura Kelloniemi wrote:

> Hello,
> 
> On 2024-10-08 at 12:49 -0400, Nicolas Pitre <nico at fluxnic.net> wrote:
>  > Admitedly I prefer when my display is updated as fast as possible.
> 
> Yes, I don't want to force this slowdown on anybody. In my testing I was
> looking for the biggest possible value of the update rate which does not
> disturb me in any way, and 75ms was that.

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.

>  > Given your explanation so far, what you do want is a bigger value than 250
>  > ms not a smaller one.
> 
> No, I want a smaller alue. My value for the update rate is 75ms which is
> smaller than 250ms.

Well... the tracking wait value is unrelated to screen updates. This 
value is used to confirm if a cursor movement should necessarily move 
the braille window back to it. Consider, for example, that you're 
reading something in a text editor away from the cursor position, and 
suddenly the editor moves the cursor to e.g. update the current time in 
the status bar and moves it back where it was. In such case you don't 
want the braille window to track the cursor position. Considering a wait 
time of 250ms, this means the cursor can move away but if it returns to 
its original position within that 250ms then the braille window location 
won't be affected. And this delay is applied only when the cursor isn't 
inside the braille window. Again, completely unrelated to screen update 
delay.


Nicolas