A new approach to text rendering
blog.atom.io
A new approach to text rendering
1–10 of 112 posts
Re: A new approach to text rendering
#2> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem.
This is a perfect example of why we need parallel restyling. :)
Re: A new approach to text rendering
#3> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. This is a perfect example of why we need parallel restyling. :)
How would that work? Breakup the screen into chunks each CPU/GPU renders?
Re: A new approach to text rendering
#4> One frustrating component of the above breakdown is the time spent recalculating styles. At this point, it looks like the only way to solve this within the current paradigm is to use CSS less and reduce the number of selectors in the application, but that’s going to be a hard fought battle given the huge number of themes in the ecosystem. This is a perfect example of why we need parallel restyling. :)
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.
Re: A new approach to text rendering
#5So, we're sort of simulating offscreen drawing by using a virtual dom? I mean don't get me wrong it's sort of nice that they did this as it's the only thing they could have done to deal with the issues I wrote in my 2014 blog post, but that also means that with a lot of effort the web is now able to do what quickdraw could almost 20 years ago...
Re: A new approach to text rendering
#6So, we're sort of simulating offscreen drawing by using a virtual dom? I mean don't get me wrong it's sort of nice that they did this as it's the only thing they could have done to deal with the issues I wrote in my 2014 blog post, but that also means that with a lot of effort the web is now able to do what quickdraw could almost 20 years ago...
You've always been able to query layout information about DOM nodes that are off screen. The virtual DOM is used for other reasons.
Re: A new approach to text rendering
#7I still really wonder about the approach of using web tech for this editor. But I haven't tried it in a while so I will do that shortly. I have been wanting more Github integration in my editor recently, ever since I saw the Xcode demo.
Re: A new approach to text rendering
#8Seems like such a wasted effort due to technology choice
Re: A new approach to text rendering
#9So, we're sort of simulating offscreen drawing by using a virtual dom? I mean don't get me wrong it's sort of nice that they did this as it's the only thing they could have done to deal with the issues I wrote in my 2014 blog post, but that also means that with a lot of effort the web is now able to do what quickdraw could almost 20 years ago...
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 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.
Re: A new approach to text rendering
#10Then 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.