Re:The web at maximum FPS: How WebRender gets rid of jank
by Ajedi32 on Tuesday October 10, 2017 @03:43PM
(#15444766)
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
by benjaminjackman on Wednesday October 11, 2017 @08:05AM
(#15449029)
Hmm that sounds like outside of missed frames or otherwise busy sites consistently using more than 25% of the frame budget more power will be required by the new approach. Isn’t that going to be the most common case?
Re:The web at maximum FPS: How WebRender gets rid of jank
by nicalsilva on Tuesday October 10, 2017 @07:20PM
(#15446092)
It depends. For a lot of web pages, the things webrender do are actually very simple and can be faster than Firefox's compositor even if there was no painting required. The expensive stuff like rasterizing glyphs are cached.
The idea is that if we can render everything at a cost that is equivalent to that of the compositor, then the benefits of the compositing infrastructure aren't clear anymore. For sure there will be pages where the compositor would have been faster for frames where no painting was required, at the end of the day it's a new architecture with new tradeoffs, but the goal is to be overall (much) faster.
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?