A simple, high performance text editor.
Greg Pomerantz
c79c142397
Root cause of the ~1GB 'Unknown' memory on large files: with word wrap on (the default), VisibleByteRange used the previously-shaped GlyphLayout.VisualLineStarts to bound the visible byte range. That layout only covers the visible window (~50 lines), not the whole document, so whenever the viewport's line count exceeded the window's visual-line count the range fell back to end=fileLen. The text shaper then laid out the ENTIRE file each frame; its internal line/glyph buffers grow to the largest layout ever shaped and are never released (document.reset() keeps the backing cap), so memory ballooned to the file size (~1.1 GB for 10 MB) and OOM-killed the process under scroll. Fix: always derive the visible range from the real-line LineIndex (or the heuristic estimate before it is ready). Word wrap needs no separate path: each real line yields >= 1 visual line, so shaping viewportHeight/lineHeight real lines always fills the viewport, and the range can never collapse to the whole file. Also fixed the pre-existing LineIndex storage mismatch: EditorLayout read TheState.Editor.LineIndex (never set; SetLineIndex had zero callers) for maxScroll and scrollByteOffset, so it always used the huge pre-index estimate. It now reads cb.LineIndex, the single source of truth; the dead EditorState.LineIndex field and SetLineIndex are removed. On-device (emulator/SwiftShader), a 10 MB file now uses ~150 MB PSS / ~230 MB RSS at steady state and stays flat under scroll (was 1.13 GB PSS / 1.5 GB RSS, growing, OOM-killed). go test -race ./... green. |
||
|---|---|---|
| .qwen | ||
| cmd/pad | ||
| doc | ||
| internal | ||
| .DS_Store | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||