Accidental layer creation(jsbin.com)
jsbin.com
Accidental layer creation
http://jsbin.com/efirip/5/quiet
5 comments
Instead of z-index hacks, you can solve for Webkit (the only browser where this quirk happens so far) with:
This is what I do... it should be noted though that some devs may not want that style rendering by default.
This is a bug in chrome: https://code.google.com/p/chromium/issues/detail?id=100666
https://code.google.com/p/chromium/issues/detail?id=122083
You will also see other artifacts when placing text with css transforms over any other compositing layer (canvas, elements with css transform/animation etc).
You will also see other artifacts when placing text with css transforms over any other compositing layer (canvas, elements with css transform/animation etc).
It's unfortunate to see claims being made about best practices for performance and behavior entirely based on what Chrome Canary does (on one platform, no less). If you're going to tell people to cover their pages in z-index, you should at least test it in other browsers to see if there's a performance penalty (or improvement) there...
This works the same way in Safari 6 on OS X Mountain Lion. z-index: 1 does the trick.
And this is a wonderful advice - losing of subpixel antialiasing on the text while something is animating on the screen was always killing me. And now I know exactly why it happens and how to fix it.
It seems to be a more general issue with Webkit, for what it's worth: I see the exact same behavior in Safari 5.1
Bug closed: Won't fix
Please contact your browser vendor.
The text in Firefox doesn't lose subpixel antialiasing, at least in my browser.
Also, it's perfectly possible to use GPU compositing with subpixel antialiased texture, you just need a separate texture to store the (Ra, Ga, Ba) pre-component "alpha" vales and either dual source blending, two rendering passes (first to apply alpha to destination, second to add color), three rendering passes (one per color), or a pixel shader that takes the pre-blend target surface as an input.
If your browser doesn't do that, file a bug.
Also, it's perfectly possible to use GPU compositing with subpixel antialiased texture, you just need a separate texture to store the (Ra, Ga, Ba) pre-component "alpha" vales and either dual source blending, two rendering passes (first to apply alpha to destination, second to add color), three rendering passes (one per color), or a pixel shader that takes the pre-blend target surface as an input.
If your browser doesn't do that, file a bug.
Sure, but once the text is cached in a layer that layer might be rotated or scaled or similar, in which case subpixel antialiased text would cause ugly artifacts. Keeping subpixel antialiased text in the layer and re-rendering the layer without subpixel antialiasing when a rotating or scaling animation starts would lead to stutters in the animation.
Looking forward to high DPI displays obsoleting subpixel antialiasing as it leads to a bunch of problems when wanting to create fluidly animating UIs.
Looking forward to high DPI displays obsoleting subpixel antialiasing as it leads to a bunch of problems when wanting to create fluidly animating UIs.
Mine either, Chrome 25 (stable) Mountain Lion.