grid: cursor-only moves (CR, LF, cursor movement) still mark their row #454
Labels
No labels
priority/P0
priority/P1
priority/P2
release/v0.1.0
status/blocked
status/planned
type/bug
type/design
type/test-gap
type/tracker
No milestone
No project
No assignees
1 participant
Due date
No due date set.
Dependencies
No dependencies set
Reference
natsukium/felis#454
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Found while measuring #447.
Problem
docs/explanation/rendering/damage-tracking.md"Correctness" says cursor-only moves must leave damage empty, since the cursor is a client-side overlay. The grid still marks the cursor row on many of them:carriage_return(crates/felis-grid/src/editing.rs),line_feed/reverse_indexfor the row they land on, and the cursor-movement handlers that callself.screen.damage.mark(self.screen.cursor.row.into())(about twenty sites inediting.rs, one insink.rs). These marks date from before the cursor became an overlay.Since #447 a scroll moves the dirty marks with the rows, so the mark a
\rleaves before each line feed now costs a whole row on the wire every frame. On a 212x93 window,lessscrolling line by line and a program printing a line every 33 ms ship 3 rows per frame: the new bottom row, the default-cell entry that precedes it for 0.1.0 clients, and the row above it, which only the\rmarked. Dropping the cursor-only marks would make that 2.Proposal
Remove the damage mark from every handler that moves only the cursor (no cell, soft-wrap bit, or sized-cell change), leaving the marks on handlers that also write cells. Confirm with
crates/felis-grid/tests/damage_correctness.rs(it compares every unmarked row against the directive-shifted prior screen, so an under-mark fails it) and the daemon mirror propertyevery_mirror_ends_each_compose_holding_the_grids_cells, then remeasure the less and pager workloads.Open question