Currently, we layout and render text a line at a time. In this context, "lines" are separated by "\n" characters, and the trailing newline, if present, is included in the line. During layout, we layout all the lines that are present in the viewport, and nothing more. Their y-offsets are estimated by the Heights tree. Then we create a LineLayer for each Line.
This works fine for normal files, but if you open a file without newlines, we'll end up laying out and rendering the entire document on load, and then again on every edit. For huge files this is prohibitively expensive and takes up a ton of memory.
Instead, we should layout and render only the LineFragments (visual lines) that appear in the viewport.
An extra consideration: when we support non-wrapped text, we'll want to do something similar in the horizontal direction. I.e. if the file is a single line and we're not doing word wrapping, we still don't want to render the entire file at once. Just the portion that's in our viewport.
This depends on #125. Storing every line fragment in a fully materialized Heights tree would be prohibitively expensive (both memory usage and Heights construction), and it would also require us to layout the document to figure out how many line fragments there are.
Currently, we layout and render text a line at a time. In this context, "lines" are separated by "\n" characters, and the trailing newline, if present, is included in the line. During layout, we layout all the lines that are present in the viewport, and nothing more. Their y-offsets are estimated by the Heights tree. Then we create a LineLayer for each Line.
This works fine for normal files, but if you open a file without newlines, we'll end up laying out and rendering the entire document on load, and then again on every edit. For huge files this is prohibitively expensive and takes up a ton of memory.
Instead, we should layout and render only the LineFragments (visual lines) that appear in the viewport.
An extra consideration: when we support non-wrapped text, we'll want to do something similar in the horizontal direction. I.e. if the file is a single line and we're not doing word wrapping, we still don't want to render the entire file at once. Just the portion that's in our viewport.
This depends on #125. Storing every line fragment in a fully materialized Heights tree would be prohibitively expensive (both memory usage and Heights construction), and it would also require us to layout the document to figure out how many line fragments there are.