5 ms·
(googler, opinions are my own. I know nothing about this project). I really hope this fixes the large-document problem. As someone that has to deal with larg
by kyrra 5y ago
(googler, opinions are my own. I know nothing about this project).
I really hope this fixes the large-document problem. As someone that has to deal with large specs (1000+ page MS Word documents), Google Docs does a not-so-great job of handling them. I also understand this is why many writers don't like Google Docs to write the entire book in, as things start slowing down when you get into the hundreds-of-pages. I don't know if this is a javascript limit issue or a rendering issue, but if it's rendering, Canvas should hopefully help.
- ZeroCool2u 5y agoI'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.
- k__ 5y agoI 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.
- worldsayshi 5y agoYeah cached changes shouldn't have anything to do with dom performance.
- worldsayshi 5y agoSwitching 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...
- cellularmitosis 5y agoYou 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.
- williamscs 5y agoBut does switching to using canvas solve that problem?
- nwsm 5y agoThe argument is that the application would be much more performant, and would handle that issue better, not necessarily avoid it.
- hctaw 5y agoEfficient 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.
- jasim 5y agoI could not find clear references with an initial search. Can you expand a bit more about this approach? Thanks.
- ctoth 5y agoI'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 https://en.wikipedia.org/wiki/Segment_tree
- hctaw 5y agoIt'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.
- joelthelion 5y agoSounds like your problem is the process that requires you to use 1000-page Word documents, not Google doc performance...
- missblit 5y agoRegardless 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.
- darkfirefly 5y agoAs 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.
- paxys 5y agoVirtual DOM is already a thing. I'm sure canvas has a ton of advantages, but memory management isn't one of them.