[BRLTTY] brltty5.2 alpine2.11 cursor tracking

[Aura Kelloniemi]

Dave Mielke <dave at mielke.cc> writes:

 > [quoted lines by Aura Kelloniemi on 2015/09/14 at 19:57 +0300]

>>I think that the problem with Dave's attempt to fix this problem was that
>>screen updates just take a longer time than what was suspected. However, for
>>top for example, the screen update takes a noticeably long time (perhaps
>>around 100 ms, but this is just a guess).

 > Note that the latest update doesn't change anything. It just parameterizes the 
 > value. Have a look in parameters.h at SCREEN_UPDATE_SCHEDULE_DELAY. You'll see 
 > that it's still 0. Please try setting it to 5 (and/or otgher values as 
 > experimentation moves you).

Hhrrm, couch, sorry - did not look at the commit contents...

So, here are the new results. Now I tested with emacs with up to four windows
all updating the mode line continuously. I also tested with elinks which also
has a "clock on status line" feature.

Values 0 and 1 are too small - there is lots of screen flicker. I could not
notice any difference between values 2 and 3. Even emacs with four windows
displaying a clock on their mode lines works, even through ssh.

I also tried values 5, 10, 20, 40 and 100, but could not get top to behave
well. So, I'd say that 2 ms is a good default.

However, I have a feature request:

Could you please split SCREEN_UPDATE_SCHEDULE_DELAY to two options:
1. INITIAL_SCREEN_UPDATE_DELAY: this amount of time would be delayed, when the
screen update occurs and it has not been preceded by a previous update. This
would prevent BRLTTY's cursor tracking to be triggered too early. After
INITIAL_SCREEN_UPDATE_DELAY has passed, braille screen is normally updated.
2. CONTINUOUS_SCREEN_UPDATE_DELAY: If after a previous update a new update
appears, it is delayed for CONTINUOUS_SCREEN_UPDATE_DELAY ms, which could be
set to a higher value than INITIAL_SCREEN_UPDATE_DELAY. This would be useful,
because:
- this could be used to prevent programs (like autoconf-configure) from
flooding the braille display with updates which the user cannot read
anyways, because they fly past so quickly,
- lowering the update rate causes less power to be consumed and thus displays
with a battery can be used for a longer period without being charged,
- refreshing the display less often probably increases its lifetime as the
cells wear out slower.

So this would be like the key press handling - long press interval would be
analogous to the initial update delay and autorepeat interval would be
analogous to continous update delay.

I wish these options could be configurable at run-time - either through the
preferences menu or /etc/brltty.conf, because users' opinions are likely to vary.

When I set SCREEN_UPDATE_SCHEDULE_DELAY 
to 100, I was able to read quite a bit of configure's output, which was very
nice, and I did not need to freeze the screen. However, delay of 100 ms is
absolute too much if the initial delay is not shorter, because it causes too
much lag when navigating menus or scrolling text files.

-- 
Aura