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!
Related
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 am doing an animation with ScrollMagic and GreenSock's TimelineMax. The animation is suppose to go in a WordPress page. However the animation has some glitches when the page is open in Chrome. This problem does not occur in Safari and Firefox. I can't test for IE.
This is how the problem looks like:
And this is how it is suppose to look like:
The most bottom part with title Your web site goes up, and the two top parts move down. As I said, it works perfect on Safari and Firefox, but on Chrome you have to scroll up and down to fix the issue. However this is not acceptable for us, since the users of our page wont see the animation properly when they first scroll down.
Here is JSFiddle of the animation. Now, this will most probably work without problems in JSFiddle, but when I put this in WordPress page it looks like on the first image. Does anybody have a clue why this happens?
I found the solution :) I don't want to delete the question, because I hope somebody will find it useful.
The solution is to increase the z-index of all the elements (images, divs, everywhere where I have z-index in the css.). I increased it for 1000 on every element and it worked.
I'm working on an animation using packery. Tiles are aligned in a grid and clicking on one is supposed to enlarge it and dynamically rearrange the tiles accordingly. The resizing is animated using CSS3 transitions. All of this works as expected in IE10 and Firefox, as demonstrated in the following codepen: http://codepen.io/anon/pen/ilkmK
The same code in WebKit-based browsers (tested on Windows) produces a frantic wiggle / shaking of the box as it is resized and repositioned.
I already submitted an issue and the problem seems to be that width and height transitions in WebKit are not optimized. Implementing the same animation using jQuery.animate improved the situation a little bit, but it doesn't get rid of the wiggle. Especially on slower systems it remains very noticable.
For now I'm using the JavaScript version as a slightly better fallbackf or webkit browsers, but it's not optimal. I have no idea where to go from here, so I was hoping Stackoverflow could help me out.
For any hints on how to make this work in Chrome/Safari, I'd be very grateful.
I just tried this in Chrome on mac and it's working fine, so I can't replicate the problem. However I have a feeling this might be to do with the fact that when webkit browsers load a page they initially generate images with 0 dimensions.
Try putting your jQuery in $(window).load(function(){ instead of $(document).ready(function(){
That would wait for images to load before executing the script.
I've got a background image that changes to another image when :hover.
I used transition to show this effect.
When transition finishes my old image reapears using the same transition when loses focus (Not hover).
Please see a working example (use chrome) :
http://jsfiddle.net/WZqrY/3/
My problem:
The second transition effect does not apears when I take out the mouse half way into the first transition. You can try this moving the mouse into the image for one second and then moving it out of the image. How can I make this go smoothly?
Note: When I use colors instead of an image this effect does work in the way I pretend.
The background image transitions seem to be an unplanned "side effect" that's not fully functional and have a very limited support amongst the browsers
"This only works on Chrome 18+ and on Webkit Nightlies built in 2012 onwards. It seems to be a side effect of the CSS4 crossfading work" - source
For now your better bet will be the "2 images in a container" solution - http://jsfiddle.net/WZqrY/4/
This will work in all browsers that support transitions.
I've noticed whilst optimising animations for use on iPad using hardware acceleration, I seem to be coming across an issue that I haven't fully been able to resolve. If you are applying webkit transforms such as translate, although the animation runs great, if in the middle of an animation occuring the user scrolls the page, when they release it causes the animation to stutter whereby it reverts to its original position and attempts to continue its animation to it's end point.
I've been looking everywhere for resolve on this issue, having seen it occur on the iPad store as well! If you have an iPad at hand and you navigate to, for example: http://webkit.org/demos/transitions-and-transforms/ , if you select an item then before the button animation has completed drag the page(scroll) then release it, you will see the animation flicker back to its original position and then repeat until its complete.
The only way I've been able to work around this is when a touchmove event occurs, I tell the animation to just stay where at its original location, which stops it from trying to repeat the transition on release, as even attempts to just tell it where to go again cause it to revert regardless (seeing as how css transitions seem not technically able to be stopped).
Has anyone found any workarounds to this issue, I'm pretty sure this is a bug on iPad as opposed to a problem with the animation (this does not involve issues regarding preserve-3d and what have you), or if I should be reporting this as an issue.
Thanks!
Not sure if I'm reading between the lines, but I suspect you might see better results if you use touchend versus touchmove or touchstart.