Page transition re-think: Smoother, faster #3217
Comments
|
This needs to be done I guess. Since this is a mobile framework, i would consider not putting too much effort into desktop browsers. Make it work great on the important mobile platforms, and make it work 'ok' on the desktop and older mobile platforms. Though I know it's platform independent, It would help jqm if it would be possible to easily a near native app using ts library (as in smoothness, rendering,etc). The other frameworks are either incomplet or difficult, so this is a big opportunity. |
|
I agree with @woutervanwijk and I'm sure you are aware of it. Regards. |
|
I am having serious issues with page transitions for Android compared to iOS |
|
Thanks, this will be a killer to have this fixed. |
|
I hate when it blinks too. |
|
As requested Todd, I'm commenting on this thread with the details about Android 4.0.1 animations. We're a little dumbfounded here that office ourselves as to why the animations appear so poorly. I'm happy to help test, so I'll hop on to the dev IRC this afternoon.
The page transitions are pretty harsh on Android 4.0, as seen in the following video which navigates the JQM demo site (http://www.youtube.com/watch?v=aHKozRk29b0). You end up with a sort of flash/double blink jumpiness before the page appears. |
|
It would be great to work with someone who has a 4.0.x device, as I don't have one. Ping me (kinblas) when you hop on dev IRC. In the meantime, when you get a chance, perhaps you can run through some of the pages I have here: and see if/when things start blinking. Those pages were me trying to figure out methodically what it is that causes the blinks. Most of the pages make NO use of jQuery Mobile and use some small JS that just kicks off the transitions. I was seeing flashes (white flashes, or flashes of previous content) upon completion of the animations, even when leaving the animations classes on. Most of the tests are set up to click once to start animation, click a 2nd time to reset for running the animation again. |
|
This is not just an issue on Android. On iOS we have the same issue. |
|
If you have a sample we can use to repro on iOS that would be great! |
|
@jblas @patrickdet here is the link: http://test.orderpass.com/app/ - sign it with: aam5p1, table number 1. |
|
@jblas - For the record, all of those demos in your link flash in Honeycomb, starting with the first. I think Android is just not able to hack any of these transforms and things aren't getting better with time. So disappointing. |
|
This is slightly(maybe more) off-topic, but it explains some of how Android handles web page rendering. It seems they are moving to a split between GPU and CPU rendering based on power and other requirements as well as tile based rendering like iOS uses. tl;dr: Android rendering getting closer to iOS style moving forward. https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s |
|
Great read, thanks for sharing! |
|
Does anyone have a solution / hack / workaround for this issue yet? I can't believe this hasn't been fixed yet. This flickering / blinking issue destroys the user experience... and, removing all transitions is not a solution; that ruins the user experience as well. |
|
@bmcintos - There isn't a quick hack/workaround for this or it would be implemented by now. We're currently working on creating some different page transitions that will appear smoother, but the biggest issue is Android. From what we can tell, using any sort of transition causes some ugly blinking so the workaround is going to be to use more modest transitions by default, maybe just simple fades until Android can get it's act together. From our testing, things are actually WORSE in 4.0 and 3.0 than in 2.3 so Google just isn't making progress on their animations. |
|
It's not just android. We test on an ipad2 and the transitions jump and blink. You probably already know this but the blinking and jumping does not happen if the page to be displayed is smaller than the screen. At least in our case. A potential work around is to use the viewport tag to ensure your page fits in the screen. Unfortunately, and this is not a jqm thing, the viewport tag doesn't work. Or maybe it does? https://discussions.apple.com/thread/3558031?start=0&tstart=0 |
|
@destryalhmns I though this was the case in my implementation, as well. Glad I wasn't the only one. |
|
I don't know if this could help, but transitions work on Nexus S with Android 4.0.3, but it takes some time before animation starts. On Galaxy Nexus with 4.0.2 there are no animations. In both cases the page completely fits into the viewport. |
|
This issue is very annoying. But what is more annoying is that nothing changed in the past last year since it was reported. I understand the some browsers suck, but you should offer an alternative for Android. It is a too big chunk of the mobile market to be ignored. |
|
Here is my what I have learned after messing with this. You need the meta name="viewport" content="foo" tag but that tag does not work if you access the site locally. Upload it to a web site and it will work. This makes transitions on an iPad about as close to perfect as you can get. As was said when I initially butted my head in here, transitions on the android are still a little messed up. The slide transition looked the best for us. It has minimal flashing and might be passable in a production system. |
|
The blinking didn't occur when working with jquery.mobile-1.0a3. Only after replacing this version with jquery.mobile-1.0, I ran into the flickering problem on Andriod. Hope this is being resolved soon cause I can't finish my apps like this. |
|
@fastpat - That's interesting...what Android device/version were you testing on? We've been doing a ton of testing on various Android devices and they seem blinky in so many ways, might be worth circling back to see what was different in a3. Were you testing on our docs pages or custom code? |
|
@toddparker I just tested it a3 on ICS on my Nexus S. The animations are not blinking indeed, but, transitions are very slow. |
|
Hi, You can check out my own basic setup with just a bit of placeholder stuff. http://360tours.nl/mobieltest/alpha.html (jquery mobile 1.0a3 & a3 css) http://360tours.nl/mobieltest/final-alphacss.html (jquery mobile 1.0 & a3 css) http://360tours.nl/mobieltest/final.html (jquery mobile 1.0 & 1.0 default css) Changing just the jquery mobile version results in flickering between 2011/12/29 Hendrik Kleinwaechter
|
|
We're working intensely on trying to find a sweet spot for transitions that are at least blink-free and show some animation frames on Android which is tough given how terrible the platform is. Seems like ICS is pretty horrible with any sort of transition which is worse than Honeycomb and that was worse than Gingerbread so things are going downhill in Android instead of better. At the moment, we have a bunch of branches in active development, each very unfinished as we try different approaches. The "fade-in-out-transition" branch is probably the most polished and it switches the default transition a simple fade out, then we scroll to the top (or restore scroll position) before fading in the new page. This uses a new minimal loader style and focuses on making transitions as fast and clean as possible. We're moving towards having this be the type of default transition we'll go with because it can be made to be smooth across most all platforms and the slide transition, though cool, isn't always appropriate when navigating (moving laterally for example) so we'd rather have people set this on links to make the opt im via global option. The "slide-transition-experimental" branch makes some tricky tweaks to the slide transition to make it more repliable in various versions of Android. There are also "new-transitions" and -b, -c, and -d versions where we're playing with how and when the loader appears which impacts smoothness. Anyway, this is a top priority and we're making good progress but Android is really challenging. Ideas, feedback and test results are appreciated. I've personally be wondering if we need to offer an option to let people shut off transitions (or stick with a simple type only) only on Android since it's performance is so bad across the board. Seems like we're hearing a lot of people are turning of transitions for all platforms because of Android and that seems like a shame. We'll keep posting more as we go. |
|
Testing on the current "fade-in-out-transition" branch. In general, it feels super fast and smooth which are our primary objectives. Perceived speed and responsiveness is really good, pages seem like local pages because there frequently isn't a loader seen and wait times are under a second on wifi. The loader looks slick and subtle. The only significant issue is I still see a jump to the top before the fade out starts instead of the jump happening between fade out and in. Still need to refine the timing/callback for this to happen during the blank page moment.
|
|
Hey Todd! Today I pushed some updates that complete a first pass at a new transition handler for this new type, since it's a different sequence than our other transitions, and needs another handler. There's a lot of overlap between these two handlers now, so if people are looking to use it alongside other existing transitions, there's more overhead than I want. Hopefully once we get this working as desired, we can figure out ways to share code across those handlers. The jump-to-top that you mentioned was indeed a problem, but now it should be gone.
By only scrolling once, and to the desired destination, we've eliminated some of the complexity, and the transition should fade from point a to point b without any visible scrolling. Another thing I added today was a fallback positioning of the loader, for platforms that don't get position:fixed right. In those cases, the loader will reposition at the center of the screen, then reposition to that spot on scroll. The fallback still needs a little refinement for positioning in some scenarios, but seems to works well on iOS4. You can test it using the "test this for loader" link on the homepage. Overall, on my emulator things look very nice, but the results vary in my iOS 4.3 device. I don't have iOS5 on hand to test. One thing I want to know is whether there is any flickr of the "to" page before it fades in. I was a little surprised to find that I could make it visible, then focus and scroll it, before fading it from 0 to 1, without it appearing before the fade. If this doesn't play out in reality, there are a number of things I can try so that it's technically there, for focus and scrolling purposes, but not yet visible, though I know there are issues in WP7 with using visibility:hidden to do this, so perhaps opacity or a transformx would work. Another minor thing: the loader gif seems to spin very slowly... sortof chugging along, and a few gif artifacts are noticeable. Think it could be a little faster? I've uploaded a snapshot to: shortened: http://bit.ly/sa6Z4B |
|
I also commented on that ICS ticket: "I agree that transitions are incrediblly poor on ICS and Google needs to address performance soon in a maintenance release. ICS running on brand new hardware has dramatically worse performance than a 2-3 year old 2.x device with even simple transitions in jQuery Mobile. Frameworks like Sencha Touch and jQuery Mobile can't work around such a fundamentally broken implementation. Based on the performance of current builds of ICS (4.0.3) on new hardware like the Galaxy Nexus, we're considering blacklisting 4.0 (and 3.0 too) from all transitions until this is improved because it impacts the user experience so significantly." |
|
I also commented. Thanks Todd! |
|
"Using a 3d transform and ideally a CSS animation is the preferred solution. The flicker was fixed in 4.0.3 Tested the attached sample, as well as the Sencha Touch and jQuery Mobile demo sites and the animations work smoothly. Check to make sure you have the most recent versions of those libraries. As a possible work around for the flicker in pre-4.0.3 versions, you can create the item to be animated with a 3d transform initially so that it doesn't flicker as it starts to animate." posted on the ticket mentioned above. |
|
This may be the reason why I do not have any flicker on my TF201,
|
|
Well, some more fun from Google it seems. They just released Google Chrome Beta on the Android market for ICS phones and tablets. If people are able, please download and try this out on your Android device. My Results:
I can add/update this list with other sites if people want me to. In my testing, iOS devices are still more smooth than Android but with the modified Browser, the differences are far more subtle. |
|
Any updates on how Google Chrome Beta is improving ICS? I know there were/are continued issues with animations and the Android Browser / ICS. I hope this makes some of those fade away. |
|
Some notes from a Google dev: "Hardware accelerated graphics Getting this right was one of the largest efforts in bringing Chrome to Android. As a result, scrolling is buttery smooth on most reasonably efficient web sites. If your site isn't as smooth as you want it to be, take a profile in the Timeline panel to see where time is being spent. Often there are patterns for avoiding layouts or style recalculations to get back into the fast zone. A notable exception is CSS animations. While Chrome's framerate is similar to other mobile browsers, they aren't nearly as smooth as they need to be. Improving them is an area of focus at the moment." |
|
It also looks like Chrome is the go-forward plan for Android, and may even become the default browser in ICS in the coming months: http://androidandme.com/2012/02/applications/goodbye-old-browser-chrome-to-become-the-standard-browser-on-android-4-0-and-above/ |
|
http://www.digitimes.com/news/a20120215PD209.html Android 5 2Q12 |
|
So where do we stand on this one @toddparker ? Should I look for any more ways to improve any particular transitions in 3d supporting browsers? If so, I think at this point, we'd be down to seeing if timeouts and such help with hiccups, but that always has the potential of introducing issues too... |
|
I think this is now solid and we can probably close this issue and open new issues for specific bugs. Might be worth doing another quick pass to see if blinks can be mitigated on longer pages. Was seeing a bit of that recently on my iPhone 4S. |
|
In my experience, flashing only occurs when other animations and form adjusments are being made via pageShow and pageBeforeShow. If it's just a transition from a plain no-events page to another plain no-events page, all is well. (I have yet to try putting all the page-specific code into the document.pageBeforeChange event, with different handling for each toPage) The flashing of the page-we-just-left is particularly likely if the page we're transitioning to has both 'pageshow' and 'pagebeforeshow' handlers. Also, I sometimes make use of a yellow 'toast' message after a user has submitted something and before a page transition occurs. This toast is very likely to cause flashing because it runs asynchronously and its fadeIn and fadeOut may thus occur at any point before, during or after the page change. |
|
By the way, how can this issue be closed if the problems continue to occur on all devices that were upgraded to 4.0.3? Surely you're not dropping this issue when most devices are still on version 2 and many are likely to get this upgrade in the coming months? |
|
I'm giving the new transitions a last push this week, mostly to see if there are any other tricks we can throw at them to make things smoother in one device or many. I'll definitely entertain any suggestions for changes, just please check through this thread to see if an idea has already been discussed before commenting. As for Android: The gist of it is, our full-page animations and that of most any other framework we've tested have never been terribly impressive in any version of Android (even, unfortunately, 4.x - but Chrome is an improvement at least). We've poured hundreds of hours into transitions workarounds to make Android smoother and have come up short. In fact, the animation performance was so bad in previous jQM versions on Android that we decided to qualify all of our transitions except for "fade" to 3D-transform supporting browser/devices. This means Android pre 4.x will always see "fade" transitions while other platforms may see another richer transition. Unfortunately, animating CSS properties other than opacity just dropped too many frames and blinked too much to be of value to the user experience - the forum and tracker are filled with comments to support this claim. Regarding all platforms: As Todd has mentioned a bunch of times in this thread, jQM does not use a "fake" javascript polyfill scroller for scrolling page content. This is a major factor in our ability to claim the broad support and accessibility that this framework aims to offer, but it also means we have to scroll the window while transitioning pages in and out, in order to end up at the right scroll distance in the new document. Scrolling the window while pages are visible tends to cause a blink or three at worst, and at best, an awkward jump - unsmooth either way. You can see this problem in all browsers in jQM versions prior to 1.1. For this reason, we changed our sequence in 1.1 to transition the first page out, scroll while the pages are hidden, and then transition the next page in. This generally makes things better, particularly in iOS and a few other devices and desktop browsers, but Android is not a whole lot better or worse. Other frameworks have written extensively on Android's animation performance, and we concur with their claims: animating content with any realistic amount CSS styles and screen real estate makes for very poor effect. Anyway, that's where we are at. We're trying to carry through with the goal of making this work as best as it can across A devices. As I'd said, I'll be happy to try suggestions if anyone has ideas for improving things this week. Take a look at jquery.transitions.js and the related CSS transitions files if you're interested in digging in. Thanks! Scott On Mar 20, 2012, at 4:24 PM, Wytze wrote:
|
|
Thanks for all the work on these transitions Scott. It's a big pain, especially when Android seems bent on making it harder for you and us at each new version. One point of advice that I haven't seen in all the threads here and on StackOverflow and elsewhere is the very simple "set transitions to 'none'". It's not very smooth and Apple-ish, but in my case it does prevent all flashing. Beside the flashing between pages that had pageBeforeShow handlers doing other kinds of animations, the strangest place I found flashing was when going straight from one dialog to another using |
|
We have upgraded our product to use the latest 1.1.0 stable version, unfortunately we are still seeing transition issues (white screen for a sec) on devices using latest android version (ice cream sandwich for ex.) and using the default browser, chrome seems to be fine. Note that we have set the global config as such: $(document).bind("mobileinit", function() { Any advice apreciated. And well done for that new version! |
|
Android's browser is...less than ideal. You can see how much Chrome works so it's mostly just poor software. You might want to try the latest build in master to see if it's any better. We mad ea few CSS tweaks for iOS webviews that could improve this. When I navigate the latest docs on 4.0.2 (ICS) or 3.0 (Honeycomb), I don't see the dreaded page blink with either the default fade or no transition. |
|
I spent the weekend trying to isolate the cause(s) of the blinky and jumpy transitions. First, I tried to get control of the scrolls that happen before and after a transition (scroll to top and scroll to last scroll). Using the scrollTo plugin and easing plugin, I got the smooth scroll I was looking for. That took care of some of the jumpiness that was occurring. Then, I spent some time trying to figure out why there was blinkiness when using fixed headers and footers. I also think some of the blinkiness was being caused by the transition durations being too small (too fast for Android anyway). So, part of the solution I think I've come up with is a mix of slowing down the default fade transition a bit and also removing the ui-header-fixed and ui-footer-fixed classes from the FROM page before starting the transition in the startIn phase. I also make the necessary adjustments to the padding-top and padding-bottom (as well as a couple other tweaks). Then, I make sure to add everything back after the transition completes in the doneIn phase of the transition. I think the end result is much improved on Android. Have a look at my forum post that contains some video captures if interested. http://forum.jquery.com/topic/to-control-the-necessary-scroll-of-a-transition-or-not-to-control-the-scroll. I'm sure there will be some kind of "usability" debate, but If people like the result I was able to achieve (I sure do) then I'd be happy to work with any of the JQM devs to get it into trunk. Or perhaps, offer some of the tweaks as options. |
|
I made one more small tweak which seems to work better with the fade transition. I changed the animation timing functions to "linear" instead of "ease-in" and "ease-out". Before the change, the fade wouldn't always fade all the way out so it would seem sluggish. With the linear timing function, it seems to be less sluggish. I'm not sure how it's going to affect other transitions though. Perhaps it would be better to only use the linear timing function with the fade transition? I'll be testing more tonight on a number of different devices and platforms. |
|
@dcarrith: |
|
@toddparker Any chance these changes rolling through will improve the next update for Chromium source? |
|
It's hard to say. I can't tell if this is more about the just the names or if the actual performance has been tweaked based on that link. Do you have any more info? |
|
I got rid of the flicker on iOS! With static header and footer. .ui-mobile, .ui-mobile .ui-page, .ui-mobile [data-role="page"], .ui-mobile [data-role="dialog"], .ui-page, .ui-mobile .ui-page-active { div.ui-header { .ui-content { .ui-footer { |
|
The planned changes for the Chromium Source haven't been worked into the nightly code yet. I'll keep an eye out. Related: W3C is putting their foot down on browser-specific CSS prefixes (the likes that makes JQM spit out tons of console warnings and validation errors). Don't know when they'll finalized it, or when browsers will obey it, but it's a good read. http://lists.w3.org/Archives/Public/www-style/2012May/0125.html |
|
@SarahJane87 thanks for sharing. This alone did the trick for me on iOS: .ui-mobile, .ui-mobile .ui-page, .ui-mobile [data-role="page"], .ui-mobile [data-role="dialog"], .ui-page, .ui-mobile .ui-page-active {
overflow: hidden;
-webkit-backface-visibility: hidden;
}I'm still using data-position="fixed". You can also remove the webkit-backface property but it created a weird white refresh on first time pageloads. |
|
I have a problem with the above code where the content's of some pages just disappear...has anyone had this?
.ui-mobile, .ui-mobile .ui-page, .ui-mobile [data-role="page"], .ui-mobile [data-role="dialog"], .ui-page, .ui-mobile .ui-page-active {
overflow: hidden;
-webkit-backface-visibility: hidden;
}
|
|
i have the same problem on an app i buit ( HTML5 CSS3 Jquery mobile & PhoneGap Cordova), when transitioning between pages it double flash's, any help please as I'm struggling with this issue . Thanks |
For the next release, improving page transitions is a top priority. It's clear that overlfow: support isn't broadly supported and that JS scrollers are heavy and only work on a small slice of our target platforms so we need to make sure that we have a solid set fo baseline transitions that work on the greatest number of platforms and are as smooth and blink-free as possible.
The text was updated successfully, but these errors were encountered: