Re: What, exactly, _is_ "line-breakout optimization"?

[G. Branden Robinson]

Hi Bill,

At 2024-05-19T16:46:39-0400, Bill Gray wrote:
>    Just out of curiosity : I gather that the idea is that this helps
>    on devices where a full refresh might take appreciable time,  and a
>    key hit might come in while that refresh was taking place that
>    would force yet another update and refresh.  (Say,  scrolling
>    through a file in a text editor,  with the cursor key held down;
>    if the time to redraw the screen was close to the key repeat rate,
>    you'd do better to stop the moment you knew a key had been hit.)
> 
>    You'd presumably want to check for a key hit after refreshing N
>    characters or N lines,  with N smaller for slower refreshes and/or
>    cheaper key hit detection.

Yes, that matches my limited understanding of the code.

https://github.com/ThomasDickey/ncurses-snapshots/blob/master/ncurses/tty/tty_update.c#L1018
https://github.com/ThomasDickey/ncurses-snapshots/blob/master/ncurses/tty/tty_update.c#L367

Too bad those line numbers will desync over time.  cgit makes it easier
to pin a URL to a tag.  I'm not sure how to do it on GitHub.  (Anyone
know?)

>    I see PDCurses had this capability,  but it was removed because
>    "the line-breakout optimization system... simply didn't work,  and
>    never has"[1].  At this point,  screen refreshes are fast enough
>    that I don't see how the capability could be useful.

You may be forgetting the poor dogs who use real terminal emulators and
operate them over network connections.  ;-)  I was in Australia for a
few years and got a reminder of how obsolete such concerns _aren't_.

But I'll grant, for a local application, typeahead(-1) seems a likely
win, or at worst harmless.

If PDCurses(-mod) apps get run over latent connections, I expect RDP or
similar gets used to attack the same problem, so I wouldn't say you made
the wrong choice for your implementation.

Regards,
Branden

signature.asc
Description: PGP signature