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.
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!
When dynamically adding custom css classes to a dc.selectMenu IE11 kicks them out when filters are applied. For now I push them in again using a renderlet. This causes "glitches"/moves content around due to added padding or widths/heights.
You can reproduce the issue by selecting an option from the select box in my block.
Is this a bug? Does anyone know a cleaner workaround not causing these glitches to appear?
We found that IE11 actually crashes on Win8 if you try to update a selectMenu! So we only render, don't attempt to redraw selectMenu on that browser.
So that's why you need to re-apply it.
In experimenting with this, I found that it was enough simply to move
.on('renderlet', ...
to the selectMenu, where it arguably belongs (because it's modifying that widget). I think this works because the select menu doesn't use any transitions, and there is no delay.
More generally, though, in any modern version of dc.js, you should really use the pretransition event, which fires before any transitions. In sum:
selectMenu.on('pretransition', function(chart){
selectMenu.select('select').classed('uk-select', true);
});
Although it's a really cool word, renderlet is rarely the right event to listen to. You'll see it in a lot of examples because it goes way back to early releases of dc.js, but it occurs after all transitions have finished.
If you use pretransition you'll have a chance to change things before the browser even refreshes at all.
I've read somewhere, (unfortunately I can't find my source again) that if a user has loaded an HTML page with a running CSS3 animation (infinite parameter) and he decides to leave it, the browser (computer) still needlessly plays the animation and so, CPU (or Acceleration hardware?) is still working for the animation although the user left the page.
So if someone could answer me, I will be pleased.
Is this fact true?
And if it's true:
Are the transitions also concerned with this issue ?
Is pausing animation (and transition if concerned) enough to avoid this problem? (I was thinking to force the pausing with an onbeforeunload event) Or should I have to do another thing ? Notice that I don't want to use "hover" to start the animations/transitions.
PS: I'm still new in CSS, javascript and know no other language. And sorry but my knowledge of English language is far from top...
If the user leaves the page completely (e.g. navigates to a whole new page or closes that tab) then the animations shouldn't keep running. If they somehow do keep being updated, it's because of a browser bug and you shouldn't worry about it anyway.
However, CSS3 animations for hidden elements (display: none;, for instance) still get evaluated, since they are keyframe-based, and there might be a keyframe sometime in the future that would cause the element to become visible again.
Imagine wanting to animate a box by first hiding it, then showing it again and making it flash. If CSS transitions would suddenly become disabled when the box is hidden, the animation would stop and the box would never appear again. And that's not what you want.
Note: profiling your web page can be done e.g. in Chrome using the Developer Tools (F12 -> Profiles). I haven't used it to profile CSS3 animations though, so I'm not sure if it can be done. You can however just take a look at Chrome's very own task manager (Shift-ESC) and see whether your website is using up a considerable amount of CPU. If that's true, then it's a sign that there might be too many animations on that page.
This is something which has been annoying me for a couple days now.
I have a spritesheet used for buttons, playing the sequence on hover/click/whatever is no problem and looks great (the image in the link is just a quick example of course). Let's say I also want that sequence to reverse on mouseout, in Firefox this plays fine. In Chrome and Safari however the image seems to 'wobble' when it plays a sequence in
reverse.
http://jsfiddle.net/SzcQn/
This example shows a quick mock up of the problem. Try mousing over the image and it will play the sequence, when you mouse out it will reverse it. In firefox this looks fine but in webkit browsers it wobbles.
The image sequence is not at fault, the code is identical for webkit and moz... I can only conclude it is a bug.
Obviously I could simply include an additional 15, in this case, frames which have the sequence reversed... but that seems a needless waste of resources.
Does anyone know of a way to resolve this issue? I have tried it with multiple sprite sheets, multiple ways of activating the animation and different webkit animation settings... the problem only occurs when it is set to play through the images from right to left, ie. in reverse.
Looks like a bug. Probably. I'd file it/search to see if anyone else has reported it.
In Webkit, will a 3D CSS transform set to repeat indefinitely, continue even when it or a parent element is hidden from view by styling (CSS)?
The reason I ask is that I am seeing unexpectedly high CPU usage on a page I am developing.
If anyone knows a good way to diagnose this issue (for example visualizing where CPU cycles are going on a page, as opposed to a blanket CPU usage per tab), I would be very grateful.
Anecdotal evidence (removal of the hidden CSS animation) would suggest that the animations do run in the background. Does anyone know how to prevent this?
In chrome 16.0.912.75, at least CSS animations appear to continue even when the element is set to visibility:hidden;. Setting display:none appears to resolve the issue.
you can debug this kind of situation with the developer tools
chrome / safari right click inspect element.
Go to the timeline tab and click on record, after that you can see what the browser is doing internally.