1

For a layout such as this: http://codepen.io/anon/pen/dPwQod

HTML:

<div class="fixed-bg one"></div>
<div class="something"></div>
<div class="fixed-bg two"></div>
<div class="something"></div>
<div class="fixed-bg three"></div>
<div class="something"></div>
<div class="fixed-bg four"></div>
<div class="something"></div>

CSS:

.one {
  background: url('http://i.imgur.com/gAn5IiK.jpg');
}
.two {
  background: url('http://i.imgur.com/dPG6S6o.jpg');
}
.three {
  background: url('http://i.imgur.com/rTQcvNZ.jpg');
}
.four {
  background: url('http://i.imgur.com/k9aRzrU.jpg');
}
.fixed-bg {
  width: 100%;
  height: 300px;
  background-size: cover;
  background-repeat: no-repeat;
  background-attachment: fixed;
}
.something {
  width: 100%;
  height: 200px;
  background: black;
}

Chrome repaints the entire viewport on scroll, making the scrolling quite laggy, especially on retina displays. You can view it in action by ticking "Show paint rectangles" in inspector.

I've looked for ways of forcing the backgrounds to individual layers, but found nothing that suits this layout. Some suggest translateZ(0) and putting the background in its own fixed div, but that only works if there is one fixed background. Is there any way to force chrome to not repaint the whole thing on scroll with multiple backgrounds such as this layout? Or at least a way to make this layout possible without the lag in Chrome?

Cheers.

ilia
  • 329
  • 3
  • 11
  • First generation macbook pro with retina owner here. The one with the crappy GPU. In your example I get 60fps when I scroll as slow or as fast as I can in Chrome. I don't think it went below 55 even once. It sounds like more work than it's worth for close to no gain. What are you testing this thing on? Dual 4k monitors? :D Also if it's mobile you're concerned about, maybe just disable background attachment for mobile?? – whaley Mar 22 '15 at 09:56
  • It's not really noticeable in my example, but it's more about the principle.. Chrome should not be repainting the whole viewport as you scroll because that's completely ridiculous. And it gets noticeable when you're serving retina-sized images as a background.. maybe this example will be more evident: http://codyhouse.co/demo/alternate-fixed-scroll-background/index.html Try unchecking background-attachment: fixed there and you'll notice how much smoother the page scrolls and how Chrome only repaints the scrollbar after. – ilia Mar 22 '15 at 15:53
  • I just checked your link. I'm still getting 60 frames. It's even faster than the CodePen example - Probably because because there aren't more than one on a screen at a time in this example on my 15inch screen. The text spreads them out. I understand what's supposed to happen, but I'm just not seeing it. – whaley Mar 22 '15 at 20:37
  • Detach Chrome DevTools from the window so that you get a full screen view of that link and look at the fps again. You should get 20-30fps and 60 when background-attachment: fixed is disabled.. In any case, that's not the point, the point is that this is a barebones example, a site with more content on the page will undoubtedly suffer.. or when it's viewed on a lower end machine for example. The point is Chrome is doing all this unnecessary work for no reason and I'm wondering if there is a workaround that allows Chrome to stop repainting the whole thing every frame. – ilia Mar 22 '15 at 20:43
  • Yup, it's detached, also on another monitor entirely. It's still 60fps. I'm not saying that it wouldn't be cool if the scroll didn't repaint the whole window, I'm just saying, I believe that the Chrome team knows what they're doing, and if they don't see a large enough performance improvement, wouldn't it be even more ridiculous to add it? – whaley Mar 22 '15 at 20:54

0 Answers0