Here's a reproduction of my issue (codepen because apparently stackoverflow's iframe affects the rendering somehow):
https://codepen.io/Ironimus/pen/GRjxpXZ
When using transform: translateZ and perspective inner elements' edges and text become blurry. It works very differently in different browsers, too. In case it also depends on screen or OS, here are a few screenshots with descriptions:
In Google Chrome transform: scale(2) is fine. Text and inner elements become blurry depending on the width of the element with perspective, and it follows very strange logic, when I set the width to 847px or higher it breaks, lower looks ok:
In Mozilla Firefox text becomes blurry if perspective/translateZ combination is used, inner elements are fine, transform: scale(2) is ok as well. width doesn't seem to affect anything:
In Safari everything is hella blurry whatever I do:
Why is it blurry at all and how do I make it right? Using transform: scale(2) for everything isn't a viable option. Are there maybe some rules I should follow to help browsers render 3D transforms with text right?
Supporting Safari isn't a priority but would still be nice
Have you tried adding a custom -webkit to the browser?
I am probably late with this answer but I recently encountered the same behavior when implementing a parallax design for a website.
This is a problem related to text being rendered as bitmaps in Safari, which are not re-rendered on transform: scale(x); but instead blown up in size.
It is possible to manually trigger a re-render of the text in some cases, however this is very finicky and there's no guaranteed way to make it work.
A more comprehensive answer to this was provided by Jack in this thread:
Transform scale() Safari bug when used on elements with border
Related
I'm implementing a Pinch to Zoom gesture in JS/CSS. In order to do so, I'm putting a fairly large image source inside a small sized IMG tag and then apply a CSS scale transform to make it bigger.
Things are working fine however on Mobile Safari the image gets blurry once I start scaling up. It should not be the case as the src for the image is big enough to support this size, but somehow Mobile Safari is displayed it as blurry.
I have debugged the issue quite a bit and found out that the culprit is an unrelated div in my page that is setting translate3d(0,0,0). To my understanding this is a Hack to trigger GPU hardware acceleration. What I believe it is happening is that because of translate3d(0,0,0), hardware acceleration is being applied when rendering the <img/>, and since the <img> is small in size, it is drawn small and the scale is applied afterwards.
To better understand the problem, I have it this code, available in in codepen here
HTML
<div>
<div id="translate3d-div"/>
</div>
<img id="image" src="https://www.trackalytics.com/assets/thumbnails/lipsum.com.jpg"/>
CSS
#translate3d-div {
/* If I remove this, the image is not blurry */
transform: translate3d(0,0,0)
}
#image {
width: 95px;
height:76px;
transform: scale(20);
}
This displays the image blurry on Mobile Safari, but it works fine on Chrome in Android.
Is there a way to fix this other than removing the unrelated translate3d? I don't think I can do that since it might be used by some other feature in the webpage.
This is because how WebKit renders transforms when hardware acceleration is enabled (like in iPhone). It increases performance dramatically but affects antialiasing when you apply a 3DTransform when no real transformation happens.
A hackfix is to set a background for the element.
#translate3d-div {
transform: translate3d(0,0,0);
background: transparent;
}
Source: https://dropshado.ws/post/6142339613/resolving-anti-aliasing-on-webkit
I couldn't find a working hack for this, but the workaround I used was to simply create a bigger HTMLImageElement and scale it down initially. Then scaled up it will not look blurry. This made my code slightly more complicated but it is working fine.
I try to make a flip-page effect in IE10.
Because IE10 doesn't support transform-style: preserve-3d;
i have to flip each side seperately. It works well in recent browsers but there is no perspective in IE10.
If i write perspective: 1000px; in the container(.flipper), backface-visibility/z-index is not working correctly.
Have a look at tis jsfiddle:
http://jsfiddle.net/wG6gk/2/
I have no clue why you have xpersepective in your CSS, IE10 is unprefixed in CSS, however the perspective property must have some kind of unit for the depth, perspective: 1000 won't be applied because the browser doesn't know what unit it is in, similarly like width and height, etc, you have to apply px, em, etc. The only browsers that assume units (and in pixels) on the perspective property are Webkit browsers, and only when it is inside the transform property.
If you do a little research you, Microsoft states:
The W3C specification defines a keyword value of preserve-3d for this property, which indicates that flattening is not performed. At this time, Internet Explorer 10 does not support the preserve-3d keyword. You can work around this by manually applying the parent element's transform to each of the child elements in addition to the child element's normal transform.
So for now, you'll just have to implement the advised fix, if you want to go down that road.
If not, you're lucky. I spent time trying to make it transition smoothly over. Originally in your fiddle, you were transforming it very awkwardly and had too many styles, in my opinion, so the techniques in this JSfiddle should help: http://jsfiddle.net/NAy2r
Explained fiddle
So basically the front content exists in the container div, while the back content exists in the back div, which exists inside the container div. This is very similar to Apple's HTML5 Card flip demo, however there is a twist when it comes to backface-visibility.
At the time that Apple relased that demo, backface-visibiity didn't work on Chrome or Firefox. Chrome had some concept of perspective, but none of backface-visibility, so when you flipped an element, you'd still see through to the back and the content of the back would show through both sides as well; However on Safari, it'd be perfect because it initially understood these concepts.
In further updates of Chrome in the months afterwards, Chrome understood the property, however it was applied literally and the back was hidden completely, regardless if you flipped it or not! What would be the point of having this property if it was going to hide the back completely no matter what? You could just apply display:none, etc, to show the back if you wanted!!
And that is where IE stands as of today, it as well doesn't recognize the 'back' of the element (an element with transform:rotateY(180deg) is considered to be the backside) like other modern browsers do. So when the element is flipped, backface-visibilty: hidden is taken literally as it was in Chrome!
So this fiddle listens on an AnimationStart event on the container div, and on the animation start, it finds the duration of the animation and it uses that to calculate halfway though the animation, so when the animation is halfway, it changes backface-visibility to visible, that way the animation smoothly transitions like it's supposed to.
This was a pain to develop, IE10 is somewhat inconsistent, as it needs time to process it the first time (probably the jQuery). Notice the relief, lack of headache and fiery red eyes. The air around you has become cooler and you can finally breathe, because now you're not alone.
Edit: I forgot to add, that if your animation or transition has a different timing, the timing in this script will have to be adjusted, as it only works with linear transitions, as of now...
I have a page that uses a number of simple animations, including some JavaScript animations that add/remove CSS classes to elements with CSS3 animations for rotations. I am not using canvas.
On the PC, the page looks great in Chrome/Safari, Firefox, and IE, but on Macs, a number of elements are completely missing on the page when it is viewed in WebKit (Chrome, and Safari 5.0.3). It looks fine in Firefox on Mac. The missing elements don't have any animations applied to them -- I don't see any connection between them and the animations.
The page validates, the CSS nearly validates except for the vendor extensions and the zoom property in my clearfix. Disabling all of the JavaScript on the page doesn't change anything. The missing elements are in the source, they are just not visible on the page.
At first glance, it looks like the Z-indexes have gotten screwy on the invisible elements. Changing these doesn't affect the problem though. Removing all of the absolute, relative, fixed positions, as well as floated elements in the entire document doesn't affect the problem. The only action that does anything, is removing all of the Webkit animations.
And when I apply all of the animations, nearly everything on the page disappears!
Here is an example of one of my animations -- simple stuff:
#-webkit-keyframes propeller {
0% {-webkit-transform: rotateX(90deg);}
50% {-webkit-transform: rotateX(1deg);}
100% {-webkit-transform: rotateX(90deg);}
}
#element {
-webkit-animation:propeller 1s linear;
-webkit-transform-origin:50% 50%;
}
Even if the animation is not called, simply the presence of the keyframes causes the page to break.
If I use this animation in particular (just the -webkit- vendor prefix), it causes a large form to vanish that is a sibling of the great-great ancestor of "#element."
Here is a link to the page I'm working on. I had nothing to do with the design:
http://goo.gl/6XXcV
All of the animations are contained in animations.css and all the JavaScript animations are in general.js.
This has been very slow-going for me since I don't have a Mac -- I'm just using Microsoft Expression Web 4 SuperPreview -- but my client has a Mac and is not impressed. Thanks in advance for any advice.
I just pulled up the site in Chrome for mac and Firefox for mac (versions 22.0.1229.94 and 14.0.1 respectively) and aside from a couple spacing differences (which are minor) the look the same. The only odd thing I see is the light blue background showing up next to all the graphics if your window is narrow enough to warrant (the seemingly needless) horizontal scroll.
What exactly is missing?
For the most part, the trouble turned out to be from bugs in Microsoft Expression Web 4 SuperPreview with their Mac/Safari 5.0.3 emulator service. When any -webkit- vendor prefixes are used for CSS3 animations, it causes elements seemingly unrelated to the animations to behave as if they have visibility:hidden.
The similar problems with the disappearing elements first reported by my client using an actual Mac with Chrome seem to be from a bad .svg font conversion that was being used with #font-face. Although the svg font was rendering on Mac/Webkit, it appeared to be destroying styles on elements in which it was used as well as parent elements. When I converted the font once more to svg using a different conversion utility, the problem resolved. Weird.
I have an issue where my css3 transformations are effecting other elements on the page and even causing them to sort of flicker. I saw another post about this but they didn't have a resolution with the issue.
http://scosha.mybigcommerce.com/w107b/ when you scroll over the navigation you see an animated css3 transformation. It works fine in firefox without flickering but with chrome and safari the effect is very obvious, you see it in the drop down menu items as well as the footer text.
Working solution for flickering elements during transition in Chrome is to set up CSS for parent node:
-webkit-backface-visibility: hidden;
The solution for me was to apply the bellow css to the parent of all affected elements.
-webkit-transform-style: preserve-3d;
-webkit-transform:translate3d(0,0,0);
This is a known issue with Macintosh text rendering on Chrome 22 (and apparently Safari). GPU acceleration causes MacOS to switch from subpixel to greyscale antialiasing which makes the font weight appear to decrease noticeably.
Update:
As the OP notes below, the fix is to apply -webkit-font-smoothing: antialiased - which applies grayscale anti-aliasing at all times. If you do this, you'll probably want to increase your font-weights all around since greyscale anti-aliased text looks notably thinner than sub-pixel
You can get the same effect by applying properties that cause the content to always be GPU accelerated (such as back-face-visibility: hidden) but because these are not guaranteed to cause GPU acceleration in future browser versions - it is more future proofed to simply specify greyscale.
I was having the same issue in Chrome but not Firefox.
The temporary fix is to add a web-kit fix and remove the transition:
-webkit-transition: none;
I'm seeing an issue where Chrome and other WebKit browsers massively blur any css-scaled content that also has translate3d applied.
Here's a JS Fiddle: http://jsfiddle.net/5f6Wg/. (View in Chrome.)
.test {
-webkit-transform: translate3d(0px, 100px, 0px);
}
.testInner
{
/*-webkit-transform: scale(1.2);*/
-webkit-transform: scale3d(1.2, 1.2, 1);
text-align: center;
}
<div class="test">
<div class="testInner">
This is blurry in Chrome/WebKit when translate3d and scale or scale3d are applied.
</div>
</div>
Are there any known workarounds for this? I get that in the simple example above, I could simply use translate rather than translate3d - the point here is to strip the code down to the bare essentials.
Webkit treats 3d transformed elements as textures instead of vectors in order to provide hardware 3d acceleration. The only solution to this would be to increase the size of the text and downscaling the element, in essence creating a higher res texture.
See here:
http://jsfiddle.net/SfKKv/
Note that antialiasing is still underpar (stems are lost) so I'm beefing up the text with a bit of text shadow.
I found that using:
-webkit-perspective: 1000;
on the container of your font or icon set kept things crisp for me after experiment with the issue on Android nexus 4.2 for sometime.
A css filter effect is a graphical operation that allows to manipulate the appearance of any HTML element. Since Chromium 19 these filters are GPU accelerates to make them super fast.
CSS3 introduces a bunch of standard filter effects, one of them is the blur fitler:
-webkit-filter: blur(radius);
The ‘radius’ parameter affects how many pixels on the screen blend into each other, so a larger value will create more blur. Zero of course leaves the image unchanged.
Set the radius to 0 will force browser to use GPU calculation and force it to keep your html element unchanged. It's like applying an "hard edges" effects.
So the best solution for me in order to fix this blurry effect was to add this simple line of code:
-webkit-filter: blur(0);
There is also a known bug that only affects retina screens. (See here: Why doesn't blur(0) remove all text blur in Webkit/Chrome on retina screens?). So in order to make it works also for retina, I recommend to add this second line:
-webkit-transform: translateZ(0);
Try this
...{
zoom:2;
-webkit-transform: scale(0.5);
transform: scale(0.5);
}
Or for a more exact approach you can call a javascript function to recalculate the transformation matrix by removing the decimal values of the matrix. see: https://stackoverflow.com/a/42256897/1834212
I came across this issue when using the isotope plugin (http://isotope.metafizzy.co/index.html) in combination with the zoom plugin (http://janne.aukia.com/zoomooz/). I built a jquery plugin to handle my case. I threw it up in a github repo in case anybody could benefit from it. - https://github.com/charleshimmer/jquery-hirestext.
I used javascript to move the text 1px top and then with 100ms after, back 1px down. It's almost unperceptive and solved the problem completely cross-browser.
body {
-webkit-font-smoothing: subpixel-antialiased;
}
or I think you could put that on a specific element, but I was having problems with one element affecting the whole site.
I think it is a problem with custom font-face fonts.
Webkit treats 3d transformed elements as textures instead of vectors
in order to provide hardware 3d acceleration.
This has nothing to do with it. You'll notice that your aliasing problem can be fixed with the addition of duration and direction information (e.g. 0.3 linear). Your having a mare trying to render everything at runtime:
Same for the above ^