I'm developing an HTML5 app for mobile/touch device deployment and are utilising PhoneGap and only targeting the iOS platform for the moment (Webkit).
My issue occurs with the CSS3 transitions (and it happens to regular jQuery animations as well) in that Webkit tends to do some strange things. For instance, in the code available to view here (http://jsfiddle.net/lvl99/dSjcj/) when you step through the pages, going back in the sequence (i.e. from page 5 to 1) will render the animation fine, however stepping forward (i.e. from page 1 to 5) will produce inconsistent rendering, mostly on the side of ugly (remember to view it in Safari. I've been using Safari 5.1.7).
I was originally developing using the jQuery Mobile framework, but the key functionality that I was using was the page routing through hashtags and the transitions, but since I had these issues with the transitions, I tried developing a simpler solution to avoid any JS/CSS conflicts with jQM. Alas, it's possible that the errors I've been coming up are actually Safari/Webkit related.
I originally used jQuery.animate() on the left property, to now using CSS3 transform technique similar to the jQM way of doing things, also to help with speed and test whether it would be more willing to render properly. Both haven't worked to varying degrees of unworkingness.
Fortunately, Firefox renders everything fine. It has no problems, however Firefox isn't the target platform and when the project is compiled within Xcode in the PhoneGap environment, it expresses the same problems that Safari has with it. When I was still using jQM with an earlier development version, Safari would render it fine (including Safari on the iPad Simulator), however UIWebView wouldn't. This made me think that perhaps it was a Nitro JS engine issue (as in, perhaps UIWebView didn't have the speed/power/capability to render the transition properly -- I've attempted to transfer all animations to CSS3 to relegate the rendering operations to the GPU).
I've used various plugins like jQuery Transit, jQuery Animate Enhanced, and TransformJS. I also tried coding my own custom transition handler within jQM and it didn't render properly (although it came the closest: worked in Firefox and Safari, just not in UIWebView).
I've had inconsistent results regarding transitioning elements with different types of content too: video, images, floated elements, multiple paragraphs are all I've tested. There was at some stage too issues with transitioning to/from the extreme ends of the sequence (i.e. 1 and 5), but now my issue is just that ascending page transition (i.e. 1 to 5).
I've spent a number of days on this, trying to address this seemingly small issue, but it's quite integral to the user experience having slide transitions like this which are contextual based on the direction the user is moving through the app. The easiest solution is to just remove the transitions, but if there's some way to understand what exactly Webkit/UIWebView is having trouble with, to create some solution for it. It's no doubt related to the flicker issue jQM experiences with transitions too. A lot of the CSS fixes for those people suggested on the web didn't work either, such as -webkit-backface-visibility: hidden and setting a default transform property -webkit-transform: rotateX(0).
It looks like the problem is that it's not animating the next item from the right (when moving up 1->2->n) but rather just '.show()'ing it when the previous item is done animating out.
Gimme a sec to step through the .js
...
Ok, I think I know what it is, what it's doing is, when it's moving right-to-left (numerically up) you can't see the new page (higher number) coming in from the left, because 'left' is moving from 100% -> 0% because the smaller number is moving out.
Ok, I think that's wrong...
If you change the 100% to 92.5% in the #-webkit-keyframes slideinleft and #-moz-keyframes slideinleft declarations then it should work for you, unfortunately I can't tell you why exactly as we (work) avoid CSS transformations as we do a lot of corporate work and so still need to support IE7+ and sometimes even 6 :(
Note that you can try a value other than 92.5% I just wanted to find the lowest sensible value that worked for you (95% didn't work)
Related
When using scaling to change the size of an HTML element containing text, the text jitters during the animation, but only if being animated with JavaScript libraries.
The jittering is most visible when the animation is slower and the text is smaller. I can't seem to figure out what causes it or how to get rid of it.
This jittering does not occur during CSS animations or animations using the fairly new JavaScript Web Animations API. It also doesn't seem to occur in some browsers. (On my iPhone)
To easily compare the different methods of animating the scaling of an element and how they appear, I made a CodePen for convenience. Before checking it out, note these points:
All the animations are using some form or imitation of the CSS property transform: scale(num); for the animation and have the same easing and duration so they can be compared more easily.
Although the jittering appears on macOS too, it is almost impossible to see on Macs with retina screens because of the high resolution.
The results I got are a reflection of the appearance of the animations on a Windows 10 machine in Google Chrome 59, although for me Microsoft Edge also showed the same results.
So my question is this: How can I prevent the text from jittering or becoming blurry when animating a scale property with JavaScript? How can I make the text in my JavaScript scale animations appear just as smooth as they do when using CSS?
You may be wondering why I don't just use CSS. The answer is because I'm frustrated with how limited CSS animation is. I would like to use advanced easing functions beyond the capabilities of a simple bezier curve (like Robert Penner's bounce and elastic functions), and use different easings on hover when the mouse enters and exits the element. This s completely my own opinion, but so far the only painless way I've found to do this is with JavaScript libraries. Besides their functionality relating to easing, most seem to offer many other capabilities which make animating much more effortless. If you know of a better way to get all the functionality I need please let me know!
What you are encountering are differences in a browser's layerizing strategy. You'll find that all the examples appear smooth in Firefox. That's because Firefox detects when script is changing a property that can animated using layers and creates a layer in response.
Although all browsers create layers when needed for declarative animations (CSS animations, CSS transitions, Web Animations API animations, and even SVG SMIL animations in some cases) not all browsers do it for Javascript animations. So, for those browsers you need to try to trick the browser into creating a layer (or, you could just file a bug on the browser, since it really should do this for you!).
Until recently, using will-change: transform was the recommended approach to get a browser to create a layer. However, Chrome changed its rendering strategy and now will-change: transform can produce very blurry results with scale animations in Chrome. Some people have succeeded in tricking Chrome to layerize at a higher resolution initially and then scaling their element down before animating. This is really unfortunate to have to do this and I can only encourage you to petition Chrome to fix this.
Also, the examples using "with HA" are not accurate. The CSS animation in (1) will also use hardware acceleration in every browser I know of--there's no need to add perspective in. Unfortunately, there is a lot of misleading information in this area (e.g. some articles claim animations can run on the GPU but that's simply not true). At the risk of self promotion, you might find an article I wrote on this last year helpful.
I have a Cordova 3.3.1 app running on Android 4.0.4 which displays images in a loop at 15 second intervals. I've currently implemented a crossfade solution as shown here: http://jsfiddle.net/chaddjohnson/ka9cqdnt/16/. This solution relies on two images layered in the same position, and the opacity of the top image changes from 0 to 100 (and vice versa) with each 15-second interval. This is the only page in the app.
Strangely I have found that if I include a CSS transition, the Cordova app will cause the device's memory to decrease over the course of an hour, and eventually the app will crash. Here is the CSS I'm using:
.ad-image:last-child {
-webkit-transition: opacity 2s ease-in-out;
transition: opacity 2s ease-in-out;
}
I'm absolutely sure this is causing the problem, as when I simply remove just these lines of CSS, the app works fine with no memory leak. And when I add the lines back, the memory leak comes back -- repeatably.
Does anyone have any ideas why this memory leak is happening? Is it a Webkit bug? Or maybe something related to my implementation (please see the jsfiddle)?
well i my self encountered this problem a lot. as the matter of fact i decided to disable every kind of effect. especially effects between pages. i think the problem rise from web-view. if you use android native code android will manage the memory and this sort of problems won't happen often. of course there are things that u can do such as disabling hardware acceleration but trust me it's still not good as what you want. my advise is to avoid any unnecessary effect as possible.
Can you try removing the :last-child property and assign a class (temporary) to your last element? Just to isolate the problem.
Is it the :last-child selector or is it the transition causing the memory leak?
Also, can you add -webkit-transform: translate3d(0,0,0); to your selector in order to activate hardware acceleration?
Native applications can access the device’s graphical processing unit
(GPU) to make pixels fly. Web applications, on the other hand, run in
the context of the browser, which lets the software do most (if not
all) of the rendering, resulting in less horsepower for transitions.
But the Web has been catching up, and most browser vendors now provide
graphical hardware acceleration by means of particular CSS rules.
Also, if it still doesn't work, try adding -webkit-backface-visibility: hidden; to your selector.
So I've been working on browser compatibility. Unfortunately, when I first designed my site, I desigend the CSS aesthetically for Firefox only. Now I'm having all sorts of trouble trying to get it to look good in the other major browsers. However, when I fix the CSS positioning such as floating a box object to the right, IE8 forces it left. I checked my code on W3C and it's okay semantically. I use little to no javascript. It's a portfolio website. The screensize shifts everything around no matter what browser, yet there is no perfect CSS for this so how does one get things to stay in place? I'm not too familiar with JQuery, but this seems to be the closest I can get to an answer. Where would I plug this into my site to see if this works?
On my website, I experience - and a lot of others do on theirs - a kind of jumping/lagging effect with Internet Explorer 11 (on a Windows 8.1 machine) when creating a parallax. On Firefox for example it is working absolutely fine.
According to my research, this is a common problem with IE11 that has no solution, but I have found a website that somehow fixed the issue (or made a Workaround?!?) :
http://focuslabllc.com/journal
But my website has the same issue as this one:
http://negativespacealphabet.com/
What are they doing differently to get it work? I appreciate your help!
Best solution I have seen to this issue is to use transition on whatever properties you are using to create the parallax.
Example, you use transform:translateY to create a parralax effect, then add:
transition:transform 10ms linear
This forces the parralax to animate smoothly.
Downside, its not fully backward compatible with older browsers
I have been using this site for awhile but never posted, I ususally found my anser.
However I seem to have a valid question regarding fading.
I have a simple javascript fade in script, with a functional cross browser opacity setting function. I am trying to fade in a large part of the webpage, but the large size or complexity of the elements in the div seems to really slow down the render in a couple browsers. In some browsers it works too fast, so I know the code works.
Does anyone know anything about the limitations of opacity rendering in different browsers?
I know I could overlay a simpler div with opacity but this just adds code when the existing code works, just not sure why there should be such drastic differences in the time it takes to apply opacity between the browsers.
jQuery has fadein/fadeout. Have you tried them?