> Hi pcwalton, I just wish Servo had clearer goals.
What is not clear about "parallelize all parts of the pipeline", "get rendering GPU bound", and "write a memory safe browser"?
> Flexbox is a great example. We were told the problems with DOM updates was caused by the old layouts and things like floats.
Nobody said that.
> So Flexbox was supposed to fix those problems.
No, it wasn't.
> I find myself frustrated that now 8 years after the iPhone the web is still incapable of so many things.
Me too.
> Here's a very simple goal: A swipeable sidebar.
You can do it already at 60 FPS. Make an overflow:scroll div and allow the user to scroll it into view. Or even just do it manually with the DOM. It will easily be 60 FPS in existing engines if you animate transforms.
> That's it. Make that happen. Do whatever it takes. Create another new layout if necessary. Create a new touch spec that's faster, if necessary. Whatever. it. takes. And then when the work is done you can point to this new widget and say that the initiative paid off.
There's nothing to do here, as you've described it.
But your comment is actually illustrative of the real problem (at least, what I think it is). We have a ton of ways to do things on the Web. Some of them are fast, and some of them are not. Web developers don't realize what the fast paths are (which is not entirely their fault). I think that all of the paths should be fast, and I think that many of Servo's technologies (such as WebRender) go a long way toward making that happen.
What's frustrating is comments like yours that describe things that the Web can clearly already do and blame browsers for supposedly being unable to do simple things. I used to think the way you did—that the Web is incapable of rendering a 60 FPS scrollable view—and then quickly discovered that, if optimized properly, there is actually no problem. What I think the problem with Web slowness is that Web authors don't know what the fast paths are, and they use things like jQuery.animate() that hit all the slow paths. That is a problem that I think we are well equipped to solve in Servo due to things like parallel style recalculation, off main thread layout, and WebRender, but it's a lot more nuanced than what you describe.
> What's frustrating is comments like yours that describe things that the Web can clearly already do and blame browsers for supposedly being unable to do simple things. I used to think the way you did—that the Web is incapable of rendering a 60 FPS scrollable view—and then quickly discovered that, if optimized properly, there is actually no problem.
I think you misunderstood the widget I'm describing. It is swipeable meaning I swipe to pull the sidebar into view and swipe to push it out of view. If I stop half way the sidebar stops where my finger stops.
Meaning the sidebar has to follow my finger, at 60fps, as I quickly swipe in and out. If such a thing is as easy you claim then a quick demo should be easy enough. I know of no such sidebars on the web that fit this requirement, but am happy to hear all of those devs (and myself!) are just terrible at their (my) jobs.
> Meaning the sidebar has to follow my finger, at 60fps, as I quickly swipe in and out. If such a thing is as easy you claim then a quick demo should be easy enough.
So what you want to do is to install a touch event handler and adjust a transform. Assume that the sidebar is pre-rasterized to a layer via will-change.
In this case, the DOM manipulation is going to be 1µs or so. Style recalculation, 1ms at most (this is a huge overestimate). Layout is skipped since you are animating a transform. Paint is skipped since you're animating a transform, the element is layerized, and all tile contents are cached. Compositing, 3ms at most (also probably a huge overestimate). Even with the most pessimistic possible numbers, I can't get anywhere near 16ms for this workload.
You need to use a Smartphone for the Demo above though (i.e. sth. that can produces touches and has a small enough screen), but it was the first thing I found by googling "hammerjs sidebar".
I'm sure that if you look at a few demos from hammer.js (which is a very - maybe the most - popular touch library) you'll understand why everything you always wanted has already been solved years ago - just not in a very easy way.
But it seems that didn't stop the world from writing libraries that make swiping, panning, and fluid 60fps easy to achieve. Just like with any other language, framework, etc. you just need to learn it well enough...
The example is broken in Chrome 47 on Android 6.0.1: Once I touch the menu putton, the sidebar immediately extends fully. Then i need to swipe right-to-left multiple times to retract it again.
We also have various real-world performance demos showing that, for certain workloads, parallelism results in measurable FPS wins. I haven't wanted to get on stage and publicize them at this point, because it's early. But we do have them.
> What, specifically, were the performance goals then?
I wasn't involved with the design of flexbox, but I didn't see performance as the main goal. Rather, the goal was to make "springs and struts"-style UI layout easy to use, because simulating it in CSS2 had bad ergonomics. Performance wins, if anything, would be relative to doing all of the layout manually in JavaScript, not relative to the CSS2 primitives.
Historically, relatively little attention has been paid to layout performance at all. The main performance wars have concerned DOM performance and JavaScript. (Look at what Dromaeo tests, for example.)
> Link?
I don't have time to create an actual demo for the specific thing you're asking for, but I've done many similar tests. Animating transforms will achieve 60FPS.
That's not what I'm asking for. You're pointing to low-level metrics and I'm asking for high-level examples of things not achievable today that Servo will enable.
> I don't have time to create an actual demo for the specific thing you're asking for, but I've done many similar tests. Animating transforms will achieve 60FPS.
Understandable, well I know there are many such widgets on the web and I've never come across one that fits my requirements. Maybe they are all doing things as slowly as possible, but I doubt it.
> That's not what I'm asking for. You're pointing to low-level metrics and I'm asking for high-level examples of things not achievable today that Servo will enable.
I don't think there are many such things as stated, because the Web is technically capable of almost anything you want to do already. Even if we were to say that CSS is too slow to do the things you need to do (which I don't believe at all), you could always do the famo.us thing, rebuild your interface in WebGL (and even maybe throw out JS in favor of asm.js), and do anything you might possibly want to do in existing engines.
What I think Servo will do is to make it easy to make Web apps fast, by eliminating the huge distinction between the slow paths and the fast paths. In my view this is the biggest performance win we can possibly get on the Web.
To be sure, I'm not saying that Web developers are bad and that it's their fault :) The browsers have created this situation, after all. It's not that the Web is incapable of being fast. It's just performance on the Web is a minefield. I think the biggest thing Servo can do is to eliminate that minefield.
What is not clear about "parallelize all parts of the pipeline", "get rendering GPU bound", and "write a memory safe browser"?
> Flexbox is a great example. We were told the problems with DOM updates was caused by the old layouts and things like floats.
Nobody said that.
> So Flexbox was supposed to fix those problems.
No, it wasn't.
> I find myself frustrated that now 8 years after the iPhone the web is still incapable of so many things.
Me too.
> Here's a very simple goal: A swipeable sidebar.
You can do it already at 60 FPS. Make an overflow:scroll div and allow the user to scroll it into view. Or even just do it manually with the DOM. It will easily be 60 FPS in existing engines if you animate transforms.
> That's it. Make that happen. Do whatever it takes. Create another new layout if necessary. Create a new touch spec that's faster, if necessary. Whatever. it. takes. And then when the work is done you can point to this new widget and say that the initiative paid off.
There's nothing to do here, as you've described it.
But your comment is actually illustrative of the real problem (at least, what I think it is). We have a ton of ways to do things on the Web. Some of them are fast, and some of them are not. Web developers don't realize what the fast paths are (which is not entirely their fault). I think that all of the paths should be fast, and I think that many of Servo's technologies (such as WebRender) go a long way toward making that happen.
What's frustrating is comments like yours that describe things that the Web can clearly already do and blame browsers for supposedly being unable to do simple things. I used to think the way you did—that the Web is incapable of rendering a 60 FPS scrollable view—and then quickly discovered that, if optimized properly, there is actually no problem. What I think the problem with Web slowness is that Web authors don't know what the fast paths are, and they use things like jQuery.animate() that hit all the slow paths. That is a problem that I think we are well equipped to solve in Servo due to things like parallel style recalculation, off main thread layout, and WebRender, but it's a lot more nuanced than what you describe.