Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The web at maximum FPS: How WebRender gets rid of jank

hacks.mozilla.org

Post reply on HN
Print view View original

201–210 of 212 posts

Re: The web at maximum FPS: How WebRender gets rid of jank

#201

Post by pcwalton »

Dylan16807 wrote: post #200
pcwalton wrote: post #198

Earlier quoted context omitted.

A compositor is already repainting the whole window on the GPU. WR doesn't change anything here.

In this use case the "painting" a compositor does from layers is copying one big rectangle. That takes next to zero time. That's not at all similar to "painting" where you actually re-render the entire visible portion of the page.

> That's not at all similar to "painting" where you actually re-render the entire visible portion of the page.

Why not?

Painting a page is mostly just copying pixels from textures too.

Re: The web at maximum FPS: How WebRender gets rid of jank

#202

Post by nicalsilva »

pcwalton wrote: post #198
Dylan16807 wrote: post #188

Earlier quoted context omitted.

What about if a tiny thing changes? Perhaps animated avatars totaling 1% of the page. Is that a scenario where the new method might use more power, because it redraws too much?

A compositor is already repainting the whole window on the GPU. WR doesn't change anything here.

Actually, Gecko's compositor knows the screen space invalid region and scissors out the rest when compositing. The invalid region is passed to the window manager. Chromium also does that although they settle for an invalid rect instead of region which is fair. There is an issue on file to do the same with webrender.

Re: The web at maximum FPS: How WebRender gets rid of jank

#203

Post by nicalsilva »

Dylan16807 wrote: post #188
nicalsilva wrote: post #158

Earlier quoted context omitted.

Let's clarify, WebRender doesn't do anything at all if nothing changed. If the content of the window is static then webrender won't wake your gpu up until it really needs to. There seem to be a confusion about video games needing to render at constant frame rate, but that is only the case in games where there is always something changing on screen. It isn't that uncommon for other types of games with more static grap…

What about if a tiny thing changes? Perhaps animated avatars totaling 1% of the page. Is that a scenario where the new method might use more power, because it redraws too much?

As pcwalton said, there is a whole lot of things on the web that are very cheap to render on a GPU if done right. For these things, a well tuned gpu renderer can easily outperform a naive compositor like what you can see in most browsers. All of the caching optimizations that one gets from a compositor can be incorporated in something like webrender (and some are, like glyphs and a bunch of other stuff). Right now webrender doesn't have all of the tweaks to avoid rendering the whole page when there is a small spinning throbber, but that will be implemented eventually (there is still a lot of work going into rendering the long tail of weird and specific things right).

Re: The web at maximum FPS: How WebRender gets rid of jank

#204

Post by btrask »

aneutron wrote: post #192
btrask wrote: post #146

Earlier quoted context omitted.

Something without a GPU: VirtualBox. Last time I tried a Servo nightly in VirtualBox (to be fair, a few months ago), it immediately crashed/aborted with a GPU-related error. I think there's a good argument for preventing security-critical apps from raw GPU access, because graphics cards and drivers are a huge amount of attack surface. I still think WebRender is the way forward, but I hope they get it working with som…

While I understand the concern about security, I think it is beside the point. The surface attack is effectively the GPU and its driver, not the web renderer. The technique that are put in place by the web renderer are and were used by game engines. If anything it'll push the GPU makers to have better drivers support. EDIT: As for the no-GPU case, it is an edge-case, in which we could for example switch to the classi…

> If you're running FF from a VM as your daily driver, there's something not right somewhere I think.

I am. QubesOS is a similar setup that runs applications in Xen VMs for security. I think you can do GPU passthrough but it's not recommended. At this point I don't think I would ever go back to running a browser "bare", even if there were no bugs, being able to have complete control over it (e.g. pausing, blocking network access, etc.) is a godsend.

I think the idea that "it'll push GPU makers to be secure" is weak. We're so far from that point it's not even on the horizon.

Re: The web at maximum FPS: How WebRender gets rid of jank

#205

Post by Dylan16807 »

pcwalton wrote: post #201
Dylan16807 wrote: post #200

Earlier quoted context omitted.

In this use case the "painting" a compositor does from layers is copying one big rectangle. That takes next to zero time. That's not at all similar to "painting" where you actually re-render the entire visible portion of the page.

> That's not at all similar to "painting" where you actually re-render the entire visible portion of the page. Why not? Painting a page is mostly just copying pixels from textures too.

You don't see a notable difference between [tens of] thousands of glyphs and bits being layered on top of each other and processed through a display list, versus copying over one single rectangle from A to B?

Re: The web at maximum FPS: How WebRender gets rid of jank

#206

Post by pcwalton »

Dylan16807 wrote: post #205
pcwalton wrote: post #201

Earlier quoted context omitted.

> That's not at all similar to "painting" where you actually re-render the entire visible portion of the page. Why not? Painting a page is mostly just copying pixels from textures too.

You don't see a notable difference between [tens of] thousands of glyphs and bits being layered on top of each other and processed through a display list, versus copying over one single rectangle from A to B?

No, I don't. It adds a small amount of vertex shading time. The GPU primitive rasterization machinery is extremely good.

Benchmark it yourself if you don't believe me!

Re: The web at maximum FPS: How WebRender gets rid of jank

#207

Post by 482794793792894 »

anon1253 wrote: post #156

Just tried it with the Nightly by setting gfx.webrender.enabled to true in about:config. Wow, that thing flies. It's seriously amazing. And so far no bugs or visual inconsistencies I could detect. Firefox is really making great progress on this front!

There's more steps necessary to enable WebRender in full capacity.

I presume, though, that things are buggier then and the potentially introduced performance drops might actually make it feel slower for now. I don't know, though, I haven't tested it with just gfx.webrender.enabled.

You can find the current full list of steps to enable WebRender here: https://mozillagfx.wordpress.com/2017/09/25/webrender-newsle...

Re: The web at maximum FPS: How WebRender gets rid of jank

#208

Post by lokimedes »

Nicely done article, but please please stop using analogous terms like quantum, rocket, atoms, jet, etc... These terms actually means something in the real world. Working in the limbo between web dev and science exacerbates how silly this is. Find your own terms please.

Re: The web at maximum FPS: How WebRender gets rid of jank

#209

Post by ChoGGi »

imtringued wrote: post #187
TylerE wrote: post #31

Earlier quoted context omitted.

A modern high-end GPU can draw upwards of 200w. Edit: Not sure why I'm being downvoted for stating a simple fact. The top-of-the-line AMD and NVidia cards have TDPs of 200-250w.

High end desktop CPUs draw around 90W and 200W GPUs can do one or two orders of magnitude more computation in specialised workloads than CPUs.

TDP for the i9-7980 is 165W, and the 1080ti is at 250W

Re: The web at maximum FPS: How WebRender gets rid of jank

#210

Post by monfera »

pcwalton wrote: post #8
vvanders wrote: post #2

Good stuff. Speaking of rendering text glyphs on the GPU, there's a really clever trick(commonly called loop-blinn, from the two authors): https://developer.nvidia.com/gpugems/GPUGems3/gpugems3_ch25.... You can pretty much just use the existing bezier control points from TTF as-is which is really nice.

If only it were as simple as just using Loop-Blinn. :) The technique described there will produce unacceptably bad antialiasing for body text. Loop-Blinn is fine if you want fast rendering with medium quality antialiasing, though. (Incidentally, it's better to just use supersampling or MLAA-style antialiasing with Loop-Blinn and not try to do the fancy shader-based AA described in that article.) Additionally, the ori…

> Loop-Blinn is fine if you want fast rendering with medium quality antialiasing

For example, when using SVG shape-rendering: optimizeSpeed ? I truly hope that SVG is going to be part of this new magic, and that the shape-rendering presentation attribute is utilized. I don't think current SVG implementations get much of a speed boost by optimizeSpeed.

Speaking of which, to what extent will SVG benefit from this massive rewrite?

Post reply on HN