I am curious to understand how does the full windowing mode works in Jupyterlab, while the docs says it only renders the visible cells, in the actual DOM it shows the content of the output cells. I was under the impression that it somehow works like virtual rendering where the DOM nodes are updated on scroll but does not seems like so, do we think its worth documenting the high level design of the full windowing mode implementation to allow extension developer take various decisions for the scalability aspects.
The cell editor is detached, but cell outputs are not detached because the state of widgets would be lost if we did that. Instead we just hide the outputs with display: none which removes them from layout and thus improves rendering performance:
Additionally, the active cell editor is never removed to allow it to recieve user input when scrolled away. The bulk of the logic for windowing is in caching, estimates sizes and making the scrolling and search work.
In future the implementation may change, as even if we do not detach the outputs from DOM, toggling display and manipulating their size is problematic. I opened some enhancement proposals on how we could make it better:
- Use `content-visibility` with `contain-intrinsic-size` for size caching in windowed notebooks · Issue #16327 · jupyterlab/jupyterlab · GitHub
- Improve native browser search support in full windowed mode (`hidden: until-found`) · Issue #16328 · jupyterlab/jupyterlab · GitHub
Though both of these proposals relay on novel browser features which are not yet widely supported.
2 Likes