Got a really tricky problem that I've been trying to figure out for a while. Essentially I'm building a large rotating wheel which has multiple elements rotating at different speeds. It's about 5000px square, but the viewport is a percentage of window height. Due to the scaling, the wheel itself is an SVG so that it looks sharp on all devices. The SVG has some pretty complicated paths in places.
It's hard to explain, so I've made a barebones demo of what I'm talking about: http://jsfiddle.net/UsVeZ/3/embedded/result/ (edit it here: http://jsfiddle.net/UsVeZ/13/). Click / tap the document to see it rotate.
Everything looks fine, and it works great on the desktop (Chrome + Safari), but when I rotate the wheel on an iPad, mobile safari lags with the rendering. The rotating animation itself is pretty smooth, but it's just the rendering that can't keep up. It's way worse with my complex SVG (which unfortunately I'm not permitted to share, but the demo gives an idea). Check it out on an iPad to see what I mean.
I'm not quite sure how to solve this problem - ideally it would be great if there was some way to keep the entire SVG in memory (not sure exactly how the rendering works or why it's doing what it's doing). If anyone has any ideas, or even a different way to approach, that would be amazing.
This is not a full answer, just a couple of strategies you could follow.
If you apply...
body {
-webkit-transform: scale(0.3);
}
You will see how Mobile Safari caches your svg, it gets pixelated and then renders correctly. If you tap and wait, it will re-cache the image when you tap again. But if you tap continously, you will notice you don't give it a chance to recache the image.
This happens in your jsfiddle too, if you tap continously eventually you don't get any choppy blocks.
So if you don't let Safari recache the image by creating an endless transition like...
$("svg").on("webkitTransitionEnd", function(){
rotation -= .01;
$("#large").css('-webkit-transform', "translate3d(0, 0, 0) rotate(" + rotation + "deg)");
$("#small").css('-webkit-transform', "translate3d(0, 0, 0) rotate(" + ( rotation * 1.5 ) + "deg)");
});
Then the cache will never go stale.
However, once you remove the scale on the body, it seems that Safari won't cache any graphics outside of the viewport. So, perhaps if you make the wheel have a full spin on load it will cache the image.
So I couldn't end up solving this issue properly on my real example. I ended up reverting to images (I split up my large image into 9 smaller images and tiled them to get around iOS' 5mp limit), and on each image I applied the following property which seems to cache the image:
-webkit-transform-style: preserve-3d;
It doesn't scale as nicely, but it works smoothly which is more important.
I actually took several different SVG's and applied a rotation to them in iOS and it ends up adding this box the instant I rotate it. I can't duplicate it in Safari or Chrome (desktop). Tried a bunch of different things to get it to stop, but no luck. I haven't been able to find much feedback online about if its a bug or not.
Just applying -webkit-transform: rotate(122deg);
Example at - http://bit.ly/QnAgFK
I found that certain [object] tags have there #documents add [html][body] tags around the svg in Safari 6. Others don't. So my assumption is this is a mime type host issue, but I've got the image/svg+xml mime-type added for .svg.
I have a dirty fix for this one.
#topParentId *{
-webkit-transform-style: preserve-3d !important;
}
I have applied css to every child of topParentId Id, and this works fine for me. It changes a little css in output but it works fine for me.
Related
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 have a simple stroke-dashoffset CSS animation on my site, it's what is causing those dashed lines to move in the gif below:
This run's fine on Chrome/Firefox on my Macbook. But when I open it on Safari there's an extreme drop in performance. Every now and then it will start running smooth for a second or so, and then go right back to being choppy and slow. It's somewhat unpredictable.
I made a codepen that uses the same SVG paths and animation - And the problem persists.
I noticed when I make the Safari window smaller, it smooths out very well. Which makes me think it has something to do with how many pixels it's drawing and how often it's drawing them.
I've been looking up this issue with every search phrase I can think of and can't find anything that would help me understand what's happening. I was wondering if anyone had any advice on a workaround for this? Or just some clarification on what is happening here. Thanks.
I have a background image that has a parent div with a transform: scale with an animation applied to it, giving the effect of the background image zooming in slowly when you land on the page.
It renders perfect accross the board except in ie 10/11. I've got all the proper pre-fixes added in, but still get a really shaky and choppy animation in ie.
I've researched and applied acceleration hacks, but nothing gives.
Does anyone have a fix or has seen something along these lines?
Thanks!
I had the same problem, but just with an image, not background image, and for me the solution was to give transform: rotate(0.01deg); to the parent of the scaled element.
Of course you will have a minimal rotation, so it depends on your css codes, if this wouldn't cause another problem.
Most likely it's because it's an image and there are not "in between" pixel renderings when doing transforms. I'm not sure there's a solution to this problem right now.
You could try doing it in canvas, though I know that's usually not the desired route to go.
It's weird iOS bug time again. I've got a header that's set to around 70vh, and (for the most part) it works well. It used to be buggy in iOS Safari but they seem to have fixed it. Apart from when you rotate the screen. It seems to double every time you rotate the viewport. 70vh becomes 140vh, then 210vh and so on.
I don't know if there's anything I can change in the CSS or on the meta viewport tag that will stop this? I'll even look entertain Javascript solutions if that's the only way around it.
Here's the site I'm referencing. All the code is on github if that's your thing.
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.