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

111–120 of 212 posts

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

#111

Post by fb03 »

fjksksvdjsjd wrote: post #103
htn369 wrote: post #94

Earlier quoted context omitted.

How complete is the Rust library and complementing open source projects comparing with golang?

It’s good. Net/http is still less mature, but this an absolutey massive golang ecosystem. You can certainly write http clients and servers today. Unicode, string processing, regex—all of these have performant, stable implementations, either in std or in crates. Recently i’ve been doing audio processing in rust; the code there is at least as good as the equivalent in go. Overall I’d say I haven’t had issues finding a…

Can you tell me about your audio coding endeavours in Rust? Are you into writing VSTs or stuff?

I've been reading more and more about Rust and while I've fallen in love with its premises I still fail to tackle the real world task of starting to do stuff with it. Would you give me some pointers?

I work with Python and C professionally and have more than 15 years coding backend stuff for un*x systems, to give you some bg.

thanks in advance!

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

#112

Post by bsimpson »

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.

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

#113

Post by madez »

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...

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

#115

Post by nachtigall »

the_duke wrote: post #100
kkarp wrote: post #90

Earlier quoted context omitted.

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.

I'm pretty sure they are aware of it. I have the same issues on Linux. It's really fast, but often it hogs one core completely and the CPU does a lot of work, sending the fans in overdrive. Especially when videos are involved. Let's hope things get ironed until a stable release in november

As said in sibling: Open a bug report at https://bugzilla.mozilla.org/

Mention Quantum Flow and "performance" in it. Make sure to attach a performance profile with https://perf-html.io/ using the linked add-on there.

I had many cases where the mozilla devs were glad about such bug reporst (especially if you are on Linux - I am too :) - which is not so often used and reported like Windows or Mac)

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

#116

Post by stcredzero »

madez wrote: post #113

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...

Why are they so obsessed with 60 fps?

Baby steps.

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

#117

Post by aneutron »

madez wrote: post #113

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...

Not an expert, but I feel that that was more of an analogy/image to give what they were aiming for. The real objective is not 60fps, the real objective is to use the GPU to do tasks that it was designed for. Plain and simple. This however, gives the user a smoother experience, and 60 fps generally gives a noticeable difference.

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

#118

Post by aneutron »

amelius wrote: post #106
aneutron wrote: post #105

Earlier quoted context omitted.

Actually, virtually every device the average grade consumer uses, has a GPU. For instance, even Atom processors have GPUs. Granted, they don't have as much cores as a full-fledged nVidia GPU, nor as much dedicated memory, but they are still GPU with several tens of cores and specialized APIs that were designed specifically for the tasks at hand. Plus, they offload (ish) the CPU.

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 rendering a web page, or spend 4ms rendering the page and 12ms on idle. From an energy standpoint, it's the same if not arguably better. (I'm not an expert but I think for simple and over repetitive shaders and the batching implemented, it is actually logical)

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

#119

Post by fjksksvdjsjd »

fb03 wrote: post #111
fjksksvdjsjd wrote: post #103

Earlier quoted context omitted.

It’s good. Net/http is still less mature, but this an absolutey massive golang ecosystem. You can certainly write http clients and servers today. Unicode, string processing, regex—all of these have performant, stable implementations, either in std or in crates. Recently i’ve been doing audio processing in rust; the code there is at least as good as the equivalent in go. Overall I’d say I haven’t had issues finding a…

Can you tell me about your audio coding endeavours in Rust? Are you into writing VSTs or stuff? I've been reading more and more about Rust and while I've fallen in love with its premises I still fail to tackle the real world task of starting to do stuff with it. Would you give me some pointers? I work with Python and C professionally and have more than 15 years coding backend stuff for un*x systems, to give you some…

I haven’t played too much with VSTs beyond a proof of concept for logic tools. However I have been doing plenty of realtime processing! It’s great: it integrates seamlessly with the C ABI—I wrote my own core audio binding (though there is already on on crates) to get to know the API, and I was far more restricted by the poor documentation than the FFI itself.

But, rust has everything you need: find-grained control over memory and ownership, inline assembly and intrinsics (I haven’t attempted autovectorization yet), bindings to common audio formats, and excellent parallelization. The datastructures are extremely expressive, especially if you come from a C background; so far I really just want better VLA support, which is mostly annoying to work around (you have to manually poke the values into memory at the correct offset in an unsafe block).

I did find that tokio-rs wasn’t suitable as I had hoped for realtime work with an async/future api and fell back onto ringbufs locked with mutexes. The good news is you can wrap that in futures itself and have a great async api that does its work eith shared memory, minimizing the viable races.

Rust will definitely be a player in the audio workstation world; right now you’ll be implementing the bindings yourself, but you can go out and write plugins today so long as the ABI is C.

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

#120

Post by to3m »

madez wrote: post #113

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...

I don't think 120Hz is as common as 144Hz. But the vast majority of displays update at 60Hz, so you might as well aim for that.
Post reply on HN