This is exactly what people used to do to optimize drawing in intensive application. You only render the visible area. The entire post explains the supporting actions needed to accomplish this for the browser. Thats why at the end of the text they talk about exploring the use of the canvas.
The actual VNC canvas was offscreen and it would only frequently display the entire thing. Which made it for a long time more efficient than modern vnc clients. I think 2010 it was still better than any other VNC client on macosx. It's by far not an uncommon technique, it's just a pain to do when your target is markup, which is what this post is all about.
Granted, it's more complex because a tile here is a chunk of markup rather than a piece of a pixmap, but still.
Your confusion (which is understandable) points to the reason why I dislike the word "render": it's extremely overloaded. Rendering as defined by QuickDraw (which you alluded to in your above comment) or the VNC client you linked to is really painting, which browsers only do for areas that are on screen or close to being on screen. Browsers have performed this optimization for decades.
What Atom is referring to by "rendering" here seems to be applying styles to parts of lines. Styling is a higher level concept than vector graphics. Partial styling is something that browsers have wanted to be able to do for a while, but it's quite complex. I've never seen an implementation of partial styling in any UI library, and certainly not in QuickDraw or VNC, which have no CSS-like concept at all.
There is no confusion from my side, I'm not sure why you're trying to use that strawman, but given your standing in the Rust community it will probably work anyway.
As I said I wrote about this issue in my blog post. You're trying all sorts of hacks here, because the fundamental issue is that your data structure is the dom and css styling, so everything that other text editors would attach as few byte metadata you used to put in the dom. Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom. Yes it's better now, but the fundamental issue is that you have a weird love relationship to the browser(and no, i'm not judging, whatever floats your boat).
This is even separate from the other problem that is the actual way of dealing with strings in javascript.
Your comments are crossing into personal incivility. We ban accounts that do that, so please edit such bits out of your posts here, regardless of how wrong anyone else may be.
> You're trying all sorts of hacks here, because the fundamental issue is that your data structure is the dom and css styling, so everything that other text editors would attach as few byte metadata you used to put in the dom.
That's part of the issue, yes. (The other, and more important, part of the issue is that CSS restyling has to occur in order for the browser to determine the changes that need to be applied to the render tree.) Note that the problem you describe has nothing to do with whether the text is off screen or not.
> Which means a simple threeliner that would be a couple of bytes in a proper designed editor, becomes the following beast in atom.
This is a misleading way to describe it, because the in-memory representation is compressed. Most of the identifiers in the DOM are compressed down to a single pointer, so they're treated as integers and only serialized when necessary. The objects are threaded together into a doubly linked tree, so the textual DOM doesn't actually live anywhere most of the time.
It's as if you took Vim's internal data structures and dumped them out into JSON. They'd be equally bloated and verbose in that format. That doesn't say anything about how efficient Vim is.
The one issue that does matter here is that the styles are currently stored as strings. It's a frequent bottleneck. There is a proposed Typed CSSOM standard [1] that is designed to address this problem. Note, again, that this has nothing to do with whether rendering happens offscreen or not.
