Switching to canvas sounds like a very roundabout way to handle an issue related to the dom growing out of hand. Surely unmounting pages that you you're not currently looking at should work?

Of course there could be many reasons but we're left to speculate...

You can ditch the off-screen rendered pages but you are still stuck with the entire 1000-page data structure. Should your current line be on page 997 or 998? You have to calculate the size of every line of every page to answer that.

Efficient 3 dimensional position or range queries (line/column/page) is a pretty well studied problem. You don't need to query every point of the space to answer anything.

I could not find clear references with an initial search. Can you expand a bit more about this approach? Thanks.

It's a task more commonly found in computational geometry (3D range query == find all the points in a data set enclosed by a cube).

There are numerous data structures that are well suited for various geometric queries like ranges/lookups (interval trees, quadtrees) as well as more text-oriented operations like cut/copy/paste/insert/merge/etc (like ropes).

I'm not familiar with the operations required to put a cursor at the right place in a document, but knowing how much research has gone into storing similar data and looking up what you need efficiently the idea of "going through all the text every time" is a big code smell.

I've used a segment tree[0] for a similar problem before. For 3D queries an R-tree may be more appropriate.

[0]: https://en.wikipedia.org/wiki/Segment_tree

But does switching to using canvas solve that problem?

The argument is that the application would be much more performant, and would handle that issue better, not necessarily avoid it.

I hope so too.

But I once read, most performance problems come from all the changes that are chached for a document and yoh can fix the problem by copying the text of an old document in a new one.

This doesn't let me hope for huge performance gains.

Yeah cached changes shouldn't have anything to do with dom performance.

I've looked at some of the public spec documents (Specifically the windowing system for Flutter desktop) that Google has hosted in GDocs and that was also the first time I noticed performance degradation. If I had to guess, I'd say there's not a better way around this performance barrier.

Virtual DOM is already a thing. I'm sure canvas has a ton of advantages, but memory management isn't one of them.

Sounds like your problem is the process that requires you to use 1000-page Word documents, not Google doc performance...

Regardless 1000 page documents _are_ the sort of things that full-fledged word processors should be able to support.

Writers need to write books, readers need to read books, and computers have more than enough resources to support these use cases.

As well, I've found Google docs is hardly able to work with 20 page documents with maybe 10 or so images. It slows down rapidly when you add images.