Hacker News Reader

Comment by RussianCow | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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.

What about if a tiny thing changes? Perhaps animated avatars totaling 1% of the page. Is that a scenario where the new method might use more power, because it redraws too much?

A compositor is already repainting the whole window on the GPU. WR doesn't change anything here.

In this use case the "painting" a compositor does from layers is copying one big rectangle. That takes next to zero time. That's not at all similar to "painting" where you actually re-render the entire visible portion of the page.

> That's not at all similar to "painting" where you actually re-render the entire visible portion of the page.

Why not?

Painting a page is mostly just copying pixels from textures too.

You don't see a notable difference between [tens of] thousands of glyphs and bits being layered on top of each other and processed through a display list, versus copying over one single rectangle from A to B?

No, I don't. It adds a small amount of vertex shading time. The GPU primitive rasterization machinery is extremely good.

Benchmark it yourself if you don't believe me!

Actually, Gecko's compositor knows the screen space invalid region and scissors out the rest when compositing. The invalid region is passed to the window manager. Chromium also does that although they settle for an invalid rect instead of region which is fair. There is an issue on file to do the same with webrender.

As pcwalton said, there is a whole lot of things on the web that are very cheap to render on a GPU if done right. For these things, a well tuned gpu renderer can easily outperform a naive compositor like what you can see in most browsers. All of the caching optimizations that one gets from a compositor can be incorporated in something like webrender (and some are, like glyphs and a bunch of other stuff). Right now webrender doesn't have all of the tweaks to avoid rendering the whole page when there is a small spinning throbber, but that will be implemented eventually (there is still a lot of work going into rendering the long tail of weird and specific things right).

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.

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.

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

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.

Reply on news.ycombinator.com