Measure the line grid with the strut the lines are laid out with - #122
Open
koldoon wants to merge 1 commit into
Open
Measure the line grid with the strut the lines are laid out with#122koldoon wants to merge 1 commit into
koldoon wants to merge 1 commit into
Conversation
`_preferredLineHeight` is the grid the editor places lines on. It was measured by a `TextPainter` without the strut, while paragraphs are laid out with `forceStrutHeight: true`. Those are different numbers — for Consolas at 13.09 logical pixels, 21 against 18 — so lines were spaced three points further apart than the height they were actually given. Two visible consequences: * a selection dragged across several lines looked striped: the boxes could not reach each other across the gap; * the three points per line accumulated into the correction the layout applies to the scroll offset, pushing the offset above the top of the document. The physics sprang it back, so scrolling up by a page ended in a bounce. Two places measure that grid — `_CodeParagraphProvider.updateBaseStyle` and `_CodeFieldRender._calculatePreferredLineHeight` — and both now use the same strut as the paragraphs. Selection boxes are snapped to the grid as well. `BoxHeightStyle.max` measures the glyph runs, which are shorter than the line; an empty line made the difference plain, since `getRangeRects` already returns a box of a full `preferredLineHeight` for it.
This was referenced Aug 20, 2026
Member
|
Thank you for your PR. The |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
_preferredLineHeightis the grid the editor places lines on. It is measured bya
TextPainterwithout the strut, while paragraphs are laid out withforceStrutHeight: true. Those are different numbers — for Consolas at 13.09logical pixels, 21 against 18 — so lines are spaced three points further apart
than the height they are actually given.
Two visible consequences, both of which our users reported:
reach each other across the gap. An empty line makes it plain:
getRangeRectsreturns a box of a full
preferredLineHeightfor it, so the distance betweenhighlighted lines changes depending on whether a line has any text on it.
correction the layout applies to the scroll offset (
correctByin_updateDisplayRenderParagraphs). Paging up pushed the offset above the topof the document — we measured −75 — and the physics sprang it back.
The change
Two places measure that grid, and both now use the same strut as the paragraphs:
_CodeParagraphProvider.updateBaseStyle_CodeFieldRender._calculatePreferredLineHeightSelection boxes are snapped to that same grid, so adjacent boxes tile exactly.
Notes
smaller than before at the same
fontHeight. Anyone who wants the previousspacing can raise
CodeEditorStyle.fontHeight; we did.the paragraph line height agree exactly, and glyphs stay inside the row.
Found while building a file manager on
re_editor. Happy to adjust anything.Related: #123 — the three points per line this PR removes are exactly what accumulates into the correction that pushes the scroll offset out of range there. Either PR stands on its own; together they make the bounce impossible rather than merely survivable.