Experiment with invisible DOM for off-screen content

[marijnh]

domenic/infinite-list-study-group#8 for background

Chrome has an experimental feature where you can create lightweight invisible DOM nodes, which wouldn't be rendered but would activate when the user searches for something that matches them. This could help reduce the issues with native search in CodeMirror (if it becomes more widely implemented), so it'd be good to see how well it works and how much memory pressure invisibly rendering a large document creates.

[rakina]

Hi there, just want to let you know that the Searchable Invisible DOM proposal had merged with Display Locking. With display locking, you get the benefits of not paying the rendering costs but retaining findability etc like Searchable Invisible DOM, and in addition to that you can update the rendering values asynchronously too.

You can try out Display Locking in Chrome Canary now (using #experimental-web-platform-features flag or --enable-blink-features=DisplayLocking) - please let us know if you run into any issues or have any questions

[marijnh]

Thanks for the update! Still planning to work on this, as soon as I have some room.

[marijnh]

Hi @rakina, is this a good place to discuss display locking as it applies to CodeMirror, or should I open an issue on the display-locking repository?

I have two questions that you can probably answer:

• Does Chrome's (in 75.0.3753.4 dev) implementation of display locking not support beforeactivate events yet? I wasn't able to get them to fire (doing .addEventListener("beforeactivate", e => console.log(e)) on the locked element).

• Does the heap size indicated under "Select JavaScript VM Instance" in the dev tools memory tab include DOM nodes? I was, unfortunately, not able to use heap snapshots, since the snapshotting never finished in my test page. The numbers given in the VM instance list seem suspiciously low—they don't grow significantly between allocating just the ton of string data that makes up the document and actually creating DOM nodes for it. But I haven't been able to find a way to get at the DOM memory usage. Any tips?

[rakina]

Hi, thanks for asking, for implementation specific bugs I'd suggest filing it out on crbug.com and cc-ing me (rakina@chromium.org), but for API-related suggestions or questions (like the find-in-page activation one you just filed) filing it on the spec repo is recommended.

On your questions:

• beforeactivate not firing, hmm that's weird, it should be working just fine. Can you show your code and explain what you're doing to trigger the event?
• DevTools Memory tab, I'm actually not familiar with that part of DevTools, so I think it's good if you can file a bug on crbug.com with what you're expecting vs what you're seeing. You can cc me and I can add DevTools people to also have a look on it.

Also I forgot to tell you about bit.ly/DisplayLockingBlink, which is a tracker for the implementation of sorts and also a quick reference guide on using it (in case the explainer is too long.. and we haven't added the size attribute to the explainer actually)

[chrishtr]

@marijnh Hi, were you able to get Display Locking to work? (I am working on this project with @rakina, @vmpstr and others.

Since April we have done a lot of work to finish off and stabilize the implementation. It should be working well now. Could you try again?

We are also planning to run an Origin Trial of Display Locking in Chrome 78, and hope you are able to participate to try it out and provide feedback. Maybe we could corrrespond via email or chat about use cases where it might work well for codemirror?

[marijnh]

@chrishtr I'm still not able to get this to fire a beforeactivate event, nor have I been able to see any speedup rendering a big document into a locked node (the main thread still seems to freeze until layout of the whole thing completes). Given how there still doesn't seem to be a lot of interest in this from other vendors, and the interface seems awkward at best, inappropriate to my use case at worst, my motivation for digging into this further is currently rather low.

[marijnh]

(Still work ongoing in https://github.com/WICG/display-locking/, which looks cleaner than the original proposal. This looks like it'll at most solve some of the issues that CodeMirror is currently addressing in its own viewport system, so though it might come in handy as an optional kludge to make search-in-page work, it's not going to have a big impact on the overall architecture of the library.)

[chrishtr]

@marijnh thanks for reviewing. Another question: in addition to find-in-page, are there any performance scalability problems CodeMirror faces that might be solved by more efficient DOM rendering?

One example: is it common to have a significant delay when switching between code files in CodeMirror, because of the need to re-render a new set of DOM? Display locking may also help with that, by providing a more effective method to cache currently-not-visible DOM.

[marijnh]

The editor is written to avoid this by rendering as little as possible. Highlighting and rendering a megabyte of text is certainly too slow to be responsive, and reflowing long lines during editing is also a noticeable problem.

[marijnh]

The content-visibility feature that seems to have come out of all this is a lot more well-designed than the early attempts, and apparently in the process of being implemented in Firefox.

That being said, it may still not be a great fit for CodeMirror, because for the kind of document sizes that we want to support, we'd still need to generate a ridiculous amount of DOM nodes to render the thousands and thousands of currently-invisible lines, which I'm pretty sure would still be impractical.