9 ms·

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,

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.

RussianCow 9y ago
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.
- s_ngularity 9y ago
  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.
  - TickleSteve 9y ago
    no, the GPU is refreshing the video output at 60Hz, the graphics are not being redrawn at 60Hz in your typical GUI application. Games are a special case of course.
  - pohl 9y ago
    The specs for my mobile GPU say that it has 1024 cores. Wouldn't it be surprising if they were all fully active regardless of workload? (It seems like low-hanging fruit for making a laptop GPU energy efficient.)
  - rayiner 9y ago
    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.
- ricardobeat 9y ago
  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.
  - vvanders 9y ago
    It depends on the GPU arch. Some of them use a separate 2D compositor that uses much less power so if you're just scrolling layers you aren't lighting up the full GPU.
  - vetinari 9y ago
    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.
    - jug 9y ago
      Also I imagine that particular path of simply sending the framebuffer is a highly optimized one.
  - zlynx 9y ago
    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-refresh-technology/2/ http://www.hardwaresecrets.com/introducing-the-panel-self-re...
  - deleted 9y ago
    [deleted]
  - nicalsilva 9y ago
    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 graphics to not render if nothing has changed.
Ajedi32 9y ago
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?
- Ajedi32 9y ago
  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_at_maximum_fps_how_webrender_gets/do6ed30/ 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.
  - benjaminjackman 9y ago
    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?

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.

RussianCow 9y ago

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.

s_ngularity 9y ago
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.
- TickleSteve 9y ago
  no, the GPU is refreshing the video output at 60Hz, the graphics are not being redrawn at 60Hz in your typical GUI application. Games are a special case of course.
- pohl 9y ago
  The specs for my mobile GPU say that it has 1024 cores. Wouldn't it be surprising if they were all fully active regardless of workload? (It seems like low-hanging fruit for making a laptop GPU energy efficient.)
- rayiner 9y ago
  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.
ricardobeat 9y ago
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.
- vvanders 9y ago
  It depends on the GPU arch. Some of them use a separate 2D compositor that uses much less power so if you're just scrolling layers you aren't lighting up the full GPU.
- vetinari 9y ago
  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.
  - jug 9y ago
    Also I imagine that particular path of simply sending the framebuffer is a highly optimized one.
- zlynx 9y ago
  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-refresh-technology/2/ http://www.hardwaresecrets.com/introducing-the-panel-self-re...
- deleted 9y ago
  [deleted]
- nicalsilva 9y ago
  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 graphics to not render if nothing has changed.

Ajedi32 9y ago

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?

Ajedi32 9y ago
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_at_maximum_fps_how_webrender_gets/do6ed30/ 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.
- benjaminjackman 9y ago
  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?