11–20 of 112 posts
Then ship Servo. It's getting annoying seeing the Servo devs constantly patting themselves on the back about how smart you are and insulting other engines that are actually serving users.
Then ship Servo. It's getting annoying seeing the Servo devs constantly patting themselves on the back about how smart you are and insulting other engines that are actually serving users.
Earlier quoted context omitted.
You've always been able to query layout information about DOM nodes that are off screen. The virtual DOM is used for other reasons.
With all due respect, no it's not. 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. Here's an application from ~2000 https://www.macintoshrepository.org/2214-vncthing The actual…
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.
Then ship Servo. It's getting annoying seeing the Servo devs constantly patting themselves on the back about how smart you are and insulting other engines that are actually serving users.
That’s unfair. It’s hardly “insulting” to talk about the benefits of a new approach. And as I understand it, Stylo will be shipping in Firefox this year.
Earlier quoted context omitted.
With all due respect, no it's not. 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. Here's an application from ~2000 https://www.macintoshrepository.org/2214-vncthing The actual…
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 "…
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.
GNU GENERAL PUBLIC LICENSE
hello
what's up
Earlier quoted context omitted.
How would that work? Breakup the screen into chunks each CPU/GPU renders?
The same way Servo (and the work-in-progress Servo port to Gecko) does it. Compute styles for every DOM node in parallel, using a work-stealing scheduler to distribute nodes among threads in a thread pool. Parent nodes must have their styles computed before children, but other than that constraint it's an embarrassingly parallel problem.
Have any of you seen the kind of stuff recent games draw in 16 ms? It's amazing! They sure as hell don't use a work-stealing scheduler in a thread pool for single vertices, though.
Earlier quoted context omitted.
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 "…
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 us…
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.
Earlier quoted context omitted.
The same way Servo (and the work-in-progress Servo port to Gecko) does it. Compute styles for every DOM node in parallel, using a work-stealing scheduler to distribute nodes among threads in a thread pool. Parent nodes must have their styles computed before children, but other than that constraint it's an embarrassingly parallel problem.
Work-stealing scheduler, thread pool? What is going on here? Have any of you seen the kind of stuff recent games draw in 16 ms? It's amazing! They sure as hell don't use a work-stealing scheduler in a thread pool for single vertices, though.
Besides, vertices are a much simpler problem than CSS styling. CSS supports hundreds of properties, all of which are parsed and cascaded differently. You have properties that are inherited and properties that are noninherited. You have properties that depend on other properties: for example, any lengths might be specified in terms of ems, which means you have to have resolved the font size first. You have properties that result in completely different render trees, for example "display". You can't effectively throw stream processors like GPUs at the problem (believe me, I've tried).
Could we do better? Sure. But every proposed replacement for CSS I've seen (e.g. Cassowary) has made the complexity problem worse. And most native styling solutions I've seen are usually just very slow implementations of CSS. Separating presentation and markup is just hard, no matter what.
Earlier quoted context omitted.
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 "…
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 us…