Dave Mielke <[email protected]> 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 _______________________________________________ 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://mielke.cc/mailman/listinfo/brltty
