I do not know how it has happened, because it worked properly at some point, but after doing some changes, I think to the main scroll container layer of the page, this started happening.
It is a weird visual glitch, I am not able of reproducing it, all that I can say is that the transition is a CSS transition with transform: translateX() and that while the transition is running both elements (new and old) get an absolute position that its remove once the animation ends. Also, there aren't any text-shadows in place.
I does not happen in firefox nor in chrome mobile, and it does not happen always, depends on if I have or not the developer tools opened, I think it might be because of the change in viewport resolution when those are open.
I have this issue as well;
fiddle
Seems it has to do with multiple layers of nested animations.
Its a bit to complicated to outline here!
I've been unable to solve stuttering in Chrome/Opera when using transitions - e.g. opacity, transform, filter etc.
For simplicity, I will focus on opacity.
Live example here:
http://www.lydkontoret.dk/index.php?pgId=20&pgName=Lyd+%26+lys
When you click on one of the pictures below the banner, a large version is displayed. I do this by adding a fullscreen div on top of page to prevent access to page elements. The div is faded in via transition on opacity. On top of this div is added further divs that holds the image.
Notice the opacity transition for the fullscreen element when clicking on a picture. On a 24" monitor with browser window maximized, chrome/opera stutters like crazy, while firefox/msie/msedge is reasonably smooth.
To complicate matters, Chrome/Opera performs ok when browser window is smaller - as rendering engine apparently is able to cope.
I've tried using will-change and translateZ(0) on the various elements involved, but chrome just doesn't care (removing the banner helps a lot - as expected, because the rendering engine then has less to deal with).
Also it's mostly the fade in that stutters. When closing the image display, transition on fullscreen element back to fully transparent often looks acceptable.
I figure my coding is ok, as Firefox etc. do the various transitions nicely. So why the problem with the blink engine used by chrome and opera?
Any thoughts??
I have an element with a -webkit-filter: blur(10px); applied to it. I'm using a CSS animation to move the element up and down with it's translateY property. When the element is animating or transitioning the blur remains but the edges become hard. When the animation or transition ends the the edges become blurred again like they're suppose to. I made a demo that shows examples of the notes that follow it.
Demo: http://jsbin.com/bofahekuko/1/edit?html,css,output
I Tried Fixing it With:
adding -webkit-font-smoothing: subpixel-antialiased; to the animating element.
forcing hardware acceleration on the animating element and adding backface-visibility: hidden on the parent
Things of Note
Happens with both CSS transitions and animations
If you move the element up and down via the CSS top property the blur filter renders correctly.
Browser Testing
Bug appears in Google Chrome (running Version 50.0.2661.86 (64-bit)) as well as in Canary.
Both Firefox and Safari (iOS and Desktop) correctly render the blur filter during the animation.
I'd really like to be able to run the animation with the translateY transition property instead of the top property. If there really isn't a fix it'd still be interesting to know what exactly is going on here to cause the problem.
Thanks in advance for any help on this.
This is a problem that's probably caused by hardware accceleration - the GPU is just moving the original blurred content without updating its background.
To fix, don't use translate or use another trick to disable hardware acceleration (like simultaneously animating margin or padding)
I have a long transform:translate transition on my website (the position bar for an audio player). The reason I chose to set a css transition for this is because this is the smoothest way (instead of js animation).
When I open the developer window during transition, the transition jumps to the final state (so the transition is gone). I'm sure this is one of the many problematic Chrome rendering quirks but I'm looking for the best way to solve this. Or is it unsolvable?
On request I can provide a code example.
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...