Virtualization (windowing, occlusion culling) support

General
1

I’m curious how suitable is Wordgard’s architecture for implementing virtualized (windowed) editor area. The ability to only mount in DOM the elements that are visible in viewport is useful with very large documents and complicated node views.

I understand that it is possible to restructure GUI so that, say,

  • the document is broken down into parts, with an editor instance for each part, and virtualization takes place outside of the editor, or
  • the user navigates across the document through means other than scrolling, and triggering those means takes care of hiding irrelevant parts[0],

but there are still cases where a single document is architecturally preferable for other reasons.

The first challenge I foresee, naively extrapolating from other windowing implementations, is that virtualization works best with a flat list of relatively uniform elements. When elements have drastically different sizes (say it has “abstract” and “body” top-level parts, where body contains nested nodes accounting for 98% of the document), virtualization is useless because presumably the entire node for body (with all of its contents) would have to be in DOM if any part of the body is visible.

An ideal virtualization-native editor, I suspect, would have to have custom typesetting, so that it can pre-calculate the height of the document and know the exact pixel position of any element within, and that seems pretty incompatible with current architecture.

However, as a compromise, perhaps virtualization could work if editor assumes a flatter schema at higher levels, e.g., avoiding sections (header + subheader + paragraph + figure rather than section > header + subsection > header + paragraph + figure).

Related PM discussions:

2

I explicitly decided against including this in the library. CodeMirror does virtualization, and it adds a lot of complexity to the library, both in code size and in how the programming interface works. I am aware that this can make some use case possible that don’t really work without virtualization, but I feel like the complexity tax would not be worth it for most users.

That being said, I am trying to to set up the library in such a way that a large part of the data structures could be reused for different view component implementations, so you could have a canvas-based, a native UI-based, a React-based, or a virtualizing editor component without rewriting the whole editing infrastructure. The abstractions to make this practical still need work, but I’d be very interested in working with someone who want to implement their own editor component to make them better.

1 Like
Strongly referencing document positions