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

81–90 of 212 posts

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

#81

Post by [deleted] »

ricardobeat wrote: post #45
RussianCow wrote: post #38

Earlier quoted context omitted.

I don't think this is actually true. If you're looking at a static page that doesn't change in any way, isn't the browser completely idle? Edit: To clarify, I realize that the screen gets refreshed ~60 times per second (depending on refresh rate), but I don't think any rendering actually happens if it doesn't need to.

The GPU is still painting the screen at a set refresh rate (your monitor’s). Some monitors have variable refresh rates, but don’t go any lower than 30hz, and depending on settings like vsync the gpu might still be churning through hundreds of wasted frames. The latest iPads can go down to 24hz to save energy due to their custom 120hz display, but that’s a rarity.

[deleted]

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

#82

Post by deafcalculus »

pohl wrote: post #13

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 frambuffer in on-chip memory. If the hash of a block hasn't changed, they don't bother re-writing that block into the framebuffer. But the GPU is still ends up running the shaders every frame.

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

#83

Post by pcwalton »

markdog12 wrote: post #77
pcwalton wrote: post #67

Earlier quoted context omitted.

Well, it's only the demo that's in TypeScript. The demo is just a fancy UI that takes the Rust-produced vertex and index buffers and uploads them to the GPU for rendering. Ideally, I don't want to have to any code duplication between the Rust WebRender and Pathfinder demo code. That said, Rust on the server and TypeScript on the client go really well together. Strong typing everywhere!

How does this work exactly with the rocket back end? Are you saying PathFinder sends back vertex and index buffers on each frame?

The meshes are all resolution independent, so they are only sent once.

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

#84

Post by jug »

vetinari wrote: post #55
ricardobeat wrote: post #45

Earlier quoted context omitted.

The GPU is still painting the screen at a set refresh rate (your monitor’s). Some monitors have variable refresh rates, but don’t go any lower than 30hz, and depending on settings like vsync the gpu might still be churning through hundreds of wasted frames. The latest iPads can go down to 24hz to save energy due to their custom 120hz display, but that’s a rarity.

In this case, the GPU just sends the content of the framebuffer to the screen. It does not re-render the content of the framebuffer, which is what the most energy is usually spent on.

Also I imagine that particular path of simply sending the framebuffer is a highly optimized one.

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

#85

Post by mxstbr »

Vinnl wrote: post #35
jacob019 wrote: post #16

Love the little stick figure representations of the threads/cores.

That's to Lin Clark's credit.

She is great at breaking down complex concepts into digestible and easily understandable pieces. Her whole Code Cartoons series is just plain awesome (https://code-cartoons.com/@linclark) and her conference talks are some of my all-time favorites!

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

#86

Post by metajack »

kadal wrote: post #71

Re: HW Acceleration Is this going to work at all on Linux?

We specifically target integrated GPUs, and several of the main developers work on linux using Intel GPUs with open source drivers. There's every reason to think this will be amazing on Linux.

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

#87

Post by pimeys »

JepZ wrote: post #80

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 side product might be the best thing Mozilla brought us. I'm truly thankful for that.

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

#88

Post by Ajedi32 »

Ajedi32 wrote: post #73
nonsince wrote: post #37

Earlier quoted context omitted.

Your browser is doing ~60fps rendering on the GPU already, it's just doing it much less efficiently. This does less work on the CPU _and_ less work on the GPU, for the same result.

I'll admit I'm certainly not an expert on browser rendering pipelines, but that's not the impression the article gave. Rather, it suggested that current browser engines may, in fact, be more efficient in terms of the absolute number of computations done. When discussing existing browsers: > But often the things on these layers didn’t change from frame to frame. For example, think of a traditional animation. The backg…

There's some interesting discussion about this very topic happening on /r/rust right now: https://www.reddit.com/r/rust/comments/75hzk5/the_whole_web_...

A particularly relevant bit:

> For the case where the CPU would have painted a single pixel, WR will certainly use a bit more power than CPU rendering with a compositor. For the case where a large portion of the screen changes, CPU renderers might miss their frame budget spending > 16ms drawing a frame, where WR will complete that task in 4ms.

> We might light up part of a GPU for longer than compositing would have, but we just saved >12ms of CPU compute. The power hypothesis is that the saved CPU compute consumes more power budget than the extra GPU compute we added. If there was no further JS code to run (app is idle) then we can go back to idle state after 4ms, instead of after 16+ms.

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

#89

Post by dom0 »

AceJohnny2 wrote: post #79
pacaro wrote: post #60

Humourously enough, when I worked on a team that was writing a graphical web browser for mobile in the late 90's [1], they used a display list for rendering. The reasoning was somewhat different, web pages were essentially static (we didn't do "DHTML"), if the page rendering process could generate an efficient display list, then the page source could be discarded, and only the display list needed to be held in memory…

Opera?

Opera is a few years older. MWC 98 + mobile = WAP browser.

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

#90

Post by kkarp »

spiderfarmer wrote: post #40
lwansbrough wrote: post #30

Earlier quoted context omitted.

I know it’s not officially released, so I’m hoping it gets fixed, but FF57 rips through my Mac’s battery life and runs insanely hot on simple JS apps. I still use it daily because it generally works, but there are a few apps I just have to go to Chrome for.

Same here. FF has always performed poorly on my 15” 2015 rMBP, but this made it worse.

I suggest reporting a bug to Bugzilla. The positive side effect will be you will see how efficiently they handle such reports. And you will get it fixed.
Post reply on HN