CSS: Enabling Webkit hardware acceleration works fine in Safari, messes up in Chrome

问题

I'm using a responsively-sized SVG clipPath to mask fixed-position divs with image backgrounds. This was all working fine (Firefox, Chrome, IE & Opera) until it was pointed out to me that it was failing in Safari. After several hours, I realised that Safari was only applying the SVG clipPath to one of the three divs it was supposed to. I googled it on Bing and found this question which is essentially the same thing but with no answer; just a comment to try forcing CSS hardware acceleration (-webkit-transform:translateZ(1px) / -webkit-transform:translate3d(0, 0, 0)).

I did that, and POW! it totally works for Safari... but now looks utterly messed up in Chrome. It's as if the repainting has gone totally out of whack (I scroll up and down, and the distorted, choppy effect in Chrome is different every time).

The problem is that both Chrome & Safari are WebKit-based, so I guess vendor prefixes aren't really going to help me here?

For reference, here's how it should look (screenshot from FF, currently looks the same in Safari):

And here's how it looks in Chrome with CSS hardware acceleration:

Ideally, I need to either a) stop the awful repaint issue in Chrome, or b) find an alternate fix for the clipPath not working on multiple elements in Safari.

回答1:

Although it is a bit hacky, I found a Chrome-specific @supports query on BrowserHacks:

@supports (-webkit-appearance:none) {
    #introwrapper .slide:not(:last-child) {
        -webkit-transform:                  none;
    }
}

This @supports query only targets Chrome >28 and Opera >14, and removes the translate3d(0, 0, 0) transform that was screwing up Chrome's repaints, but retains the CSS hardware acceleration for Safari.

来源：https://stackoverflow.com/questions/31079044/css-enabling-webkit-hardware-acceleration-works-fine-in-safari-messes-up-in-ch

标签

css

google-chrome

safari

clip-path