Re: HW Acceleration
Is this going to work at all on Linux?
The web at maximum FPS: How WebRender gets rid of jank
71–80 of 212 posts
Re: The web at maximum FPS: How WebRender gets rid of jank
#72Earlier quoted context omitted.
The Radeon Pro 560 on my MacBook Pro can draw "up to 75W". I don't know anything about how it manages power, but I do recall that Apple recommended in a WWDC session on writing energy-efficient apps that one should be careful to not trigger the discrete GPU when the integrated Intel GPU is sufficient. So that leads to another question: on my machine, which GPU would Webrender be using? I suppose I could find out expe…
Since the 15" MBP charger can deliver up to 87W, if you have full power draw on the MBP will you actually not be able to fully supply power over AC? I assume that the CPU also takes up around 20-30W.
The MBPs pull power from both AC and the battery if needed.
Re: The web at maximum FPS: How WebRender gets rid of jank
#73Now 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?
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 background doesn’t change, even if the characters in the foreground do. It’s a lot more efficient to keep that background layer around and just reuse it.
> So that’s what browsers did. They retained the layers. Then the browser could just repaint layers that had changed.
Then, later in the article, when discussing WebRender:
> What if we removed this boundary between painting and compositing and just went back to painting every pixel on every frame?
(Emphasis mine.)
So is WebRender less efficient in terms of power usage? Or is there some other factor that offsets the cost of this extra work?
Re: The web at maximum FPS: How WebRender gets rid of jank
#74Is it going to use Vulkan? Sounds like a good fit for proper parallelized rendering. UPDATE: Ah, I see it's mentioned in the future work: https://github.com/servo/webrender/wiki#future-work Vulkan? This could possibly make some of the serial steps above able to be parallelized further. So it will be using OpenGL then?
The awesome folks at Szeged University have been working with our team on both Vulkan and native DX11 backends!
That's great!
Re: The web at maximum FPS: How WebRender gets rid of jank
#75Earlier 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.
Intel GPUs support Panel Self Refresh. Tablet and laptop panels can go very slow. Less than 24 FPS, for sure! It is whatever the low end is on their LCD controller (they forget over time, like DRAM).
This article has some diagrams and explanations: http://www.hardwaresecrets.com/introducing-the-panel-self-re...
Re: The web at maximum FPS: How WebRender gets rid of jank
#76Earlier 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 drawing 60 times a second regardless of whether the page is static. Not sure how they do their streaming to the GPU, but there will be state changes every time you scroll, or click a button, etc., even on a static page.
There is a difference between drawing the frame into the frame buffer, and scanning the frame buffer out to the display. If you application is coded at all sanely, only the latter is happening at 60 Hz with a static page.
Re: The web at maximum FPS: How WebRender gets rid of jank
#77Earlier quoted context omitted.
Really cool work. Can't wait until we can give PathFinder a go in FF for text, and hopefully even SVG, :) BTW, I see you implemented PathFinder in TypeScript as well. What do you think of it, especially since I assume a lot of your recent programming has been in Rust?
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?
Re: The web at maximum FPS: How WebRender gets rid of jank
#78Earlier quoted context omitted.
They do, but we're targeting Intel HD quality graphics, not gaming-oriented NVIDIA and AMD GPUs. That said, even Intel GPUs can often deal with large numbers of draw calls just fine. It's mobile where they become a real issue. Aggressive batching is still important to take maximum advantage of parallelism. If you're switching shaders for every rect you draw, then you frequently lose to the CPU.
Speaking of batching, I look at this demo [1] on my mobile phone, and I can get ~3500 sprites without dropping below 60FPS. A web page may not be able to reuse as much image data, I know. But smart game engines frequently look for ways to better batch sprites. And technically speaking, if you're using a Z-buffer, you don't need to sort opaque layers at all . You can draw the layers in back and then draw more layers i…
Safari obviously has some optimization’s being used. On my iPhone 7 it had no issues at all until around 60k. At that point adding new bunnies would slow it down but as soon as you stopped touching it would pop back up to 60fps.
I had to get to hundreds of thousands (maybe 250k?) and it started bouncing between 40 and 60.
Very neat.
Re: The web at maximum FPS: How WebRender gets rid of jank
#79Humourously 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?
Re: The web at maximum FPS: How WebRender gets rid of jank
#80While 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.