131–140 of 212 posts
Great write-up - thanks for sharing. The name "WebRender" is unfortunate though. Things with a "Web" prefix - "Web Animations", "WebAssembly", "WebVR" - are typically cross-browser standards. This is just a new approach Firefox is using for rendering. It doesn't appear to be part of any standard.
Earlier quoted context omitted.
With a compositor you're already drawing every pixel every frame on the GPU, whether it's just a cursor blinking or not. The WR approach basically only adds a negligible amount of vertex shading time.
But only on a change... So if the cursor blinks every second, you would be doing the render/composite at that point.
Earlier quoted context omitted.
How about energy use? PS: And my second point?
There is a comment in this thread that explains this very well. 1) So the average CPU can do arroung several GFLOPS, the GPU however, even the integrated, can do some TFLOPS. S 2) CPUs have syncronization primitives, re-ordering, execution permissions, all sorts of besides the task ops they have to enforce. GPUs for the most part do not care about any of that. From 1 and 2, you could spending 16ms classically renderi…
Maybe 15 years ago.
I think 200 - 1000 GFLOPs is common modern era CPU performance. A single core can do 32 floating point operations per clock cycle. Half that, if you don't count multiply accumulate as two ops. Drop another half if you want 64-bit floats.
Why are they so obsessed with 60 fps? 120 fps looks considerably better, and there are other effects like smear and judder that significantly decrease even with significantly higher frame rates, say 480 fps [1]. [1] http://blogs.valvesoftware.com/abrash/down-the-vr-rabbit-hol...
"People talk about 60fps like it's the end game, but VR needs 90fps, and Apple is at 120. Resolution also increasing. GPUs are the only way. Servo can't just speed up today's web for today's machines. We have to build scalable solutions that can solve tomorrow's problems."
Now that this is closer to shipping, I'm curious what impact this would have on battery life. On the one hand, this is lighting up more silicon; on the other hand: a faster race to sleep, perhaps? Have there been any measurements on what the end result is on a typical modern laptop?
I have some experience with immediate mode UIs. These UIs and Game engines typically burn CPU and GPU even for an idle menu on the screen. I suspect that Mozilla will only re-render and composite on actual changes. Otherwise the power draw will be quite noticeable. The benefit of this new arch will be that they can guarantee 60 fps during that time.
Just to give more perspective, invalidation is not free, and there are cases where invalidation itself takes longer than your frame budget. Also, in the case where you have to repaint everything or almost everything anyway, invalidation just made your problem worse since you spent cycles figuring out you can't skip any work.
Now that this is closer to shipping, I'm curious what impact this would have on battery life. On the one hand, this is lighting up more silicon; on the other hand: a faster race to sleep, perhaps? Have there been any measurements on what the end result is on a typical modern laptop?
Games eat a lot of power by rendering this way. So, definitely a concern, and I'd want to see benchmarks before switching from Safari on my macbook. That said, GPUs are pretty clever about this. A big chunk of power consumption comes from IO. i.e., moving data from the GPU to the off-chip DRAM. Mobile GPUs optimize for static scenes where nothing is changing by keeping hashes of small blocks (say 32x32 pixels) of the…
> What if we stopped trying to guess what layers we need? What if we removed this boundary between painting and compositing and just went back to painting every pixel on every frame? This feels a bit like cheating. Not all devices have a GPU. Would Firefox be slow on those devices? Also, pages can become arbitrarily complicated. This means that an approach where compositing is used can still be faster in certain circ…
That is certainly true, but a) the cases where you can do everything as a compositor optimization are very few (transform and opacity mostly) so aside from a few fast paths you'd miss your frame budget all the time there too, and b) we have a lot of examples of web pages that are slow on CPU renderers and very fast on WebRender and very few examples of the opposite aside from constructed edge case benchmarks. Those we have found had solutions and I suspect the other cases will too.
As resolution and framerate scale, CPUs cannot keep up. GPUs are the only practical path forward.
Earlier quoted context omitted.
There is a comment in this thread that explains this very well. 1) So the average CPU can do arroung several GFLOPS, the GPU however, even the integrated, can do some TFLOPS. S 2) CPUs have syncronization primitives, re-ordering, execution permissions, all sorts of besides the task ops they have to enforce. GPUs for the most part do not care about any of that. From 1 and 2, you could spending 16ms classically renderi…
To come back to my second point, let's say we make a webpage arbitrarily more complex. Where does the tipping point lie, where compositing would become more favorable (in terms of time and energy) than repainting everything on every frame? Also, what (time and energy) savings could compositing bring if implemented on the GPU? (versus repainting everything on the GPU).
Another savings (memory, time, unsure about energy) comes from not having to upload giant pixel buffers to the GPU.
Earlier quoted context omitted.
I've been working professionally with Rust for a year now. When I got over the first wall, it has become the best tool I've had for creating backend applications. I have history with at least nine different languages during my professional career, but nothing comes close giving the confidence and ergonomics than the tools Rust ecosystem provides. Firefox, especially the new Quantum version is awesome. But Rust as a s…
nice! can you talk more about Rust's tooling? How do you debug? What IDE or text editor do you feel comfy with? Do you have/use/need autocomplete? I'm coming from a a Python background and I'm too spoiled by Pycharm's insane tooling and autocomplete and stuff.. I wanna trail de Rust path too! thanks in advance.
If you're interested in trying out a Rust IDE, those are the two I'd try and see how you find them.
While I would consider myself more a Golang fan than a Rust fan, I am impressed by the speed by which the Mozilla team is changing fundamental parts of their browser and somehow I believe rust has something to do with that speed.
I've been working professionally with Rust for a year now. When I got over the first wall, it has become the best tool I've had for creating backend applications. I have history with at least nine different languages during my professional career, but nothing comes close giving the confidence and ergonomics than the tools Rust ecosystem provides. Firefox, especially the new Quantum version is awesome. But Rust as a s…