Page transition re-think: Smoother, faster #3217

Closed
toddparker opened this Issue Dec 5, 2011 · 162 comments

Projects

None yet
@toddparker
Contributor

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.

  • need a re-think to embrace the constraints we have
  • scrolling the docs can't be avoided, but we can hide the jumpiness = introduce 1-2 new transitions that are smooth on all our platforms and work within the performance realities and constraints we have
  • video sketch for animations (slow to illustrate the steps) - http://www.youtube.com/watch?v=di3-fz5TZKQ
  • consider packing the new transitions with the switch from keyframe-based animations to transitions so we can package these with Opera, Firefox and IE10 support
  • speed up page load/enhancement/transition time overall
@jblas jblas was assigned Dec 5, 2011
@woutervanwijk

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.

@karol-f
karol-f commented Dec 5, 2011

I agree with @woutervanwijk and I'm sure you are aware of it. Regards.

@ghost
ghost commented Dec 6, 2011

I am having serious issues with page transitions for Android compared to iOS

@hendricius

Thanks, this will be a killer to have this fixed.

@ghost
ghost commented Dec 13, 2011

I hate when it blinks too.

@justinribeiro

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.

  • Device: Samsung Galaxy Nexus GSM
  • OS: Android 4.0.1
  • Affected Version: 1.0.1 Final

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.

@jblas
Contributor
jblas commented Dec 14, 2011

@justinribeiro

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:

http://goo.gl/oz4NY

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.

@patrickdet

This is not just an issue on Android. On iOS we have the same issue.

@jblas
Contributor
jblas commented Dec 14, 2011

@patrickdet

If you have a sample we can use to repro on iOS that would be great!

@hendricius

@jblas @patrickdet here is the link: http://test.orderpass.com/app/ - sign it with: aam5p1, table number 1.

@toddparker
Contributor

@jblas - For the record, all of those demos in your link flash in Honeycomb, starting with the first.
Also confirming the same result from @justinribeiro on ice cream sandwich (4.0) on his Nexus (he noted this in IRC).

I think Android is just not able to hack any of these transforms and things aren't getting better with time. So disappointing.

@masteinhauser

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

@jblas
Contributor
jblas commented Dec 15, 2011

@masteinhauser

Great read, thanks for sharing!

@Brian-McIntosh

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.

@toddparker
Contributor

@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.

@destryalhmns

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

@tehraven

@destryalhmns I though this was the case in my implementation, as well. Glad I wasn't the only one.

@gehriga
gehriga commented Dec 23, 2011

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.

@kenjiru
kenjiru commented Dec 24, 2011

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.

@destryalhmns

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.

@fastpat
fastpat commented Dec 29, 2011

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.

@toddparker
Contributor

@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?

@hendricius

@toddparker I just tested it a3 on ICS on my Nexus S. The animations are not blinking indeed, but, transitions are very slow.

@fastpat
fastpat commented Dec 29, 2011

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
transitions on my samsung galaxy II.

2011/12/29 Hendrik Kleinwaechter
reply@reply.github.com:

@toddparker I just tested it a3 on ICS on my Nexus S. The animations are not blinking indeed, but, transitions are very slow.


Reply to this email directly or view it on GitHub:
#3217 (comment)

@toddparker
Contributor

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.
If anyone wants to give these a test and tell us how things are looking in ICS and other platforms (keep in mind these can be pretty busted), please do.

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.

@toddparker
Contributor

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.

  • Android 2.1 - Very smooth fades, no blinks. Loader not positioned visibly most times.
  • Android 2.3 - Smooth fades, no blinks. Loader positioned correctly but gif framerate isn't that smooth
  • Honeycomb - Fades show 2-3 frames at best, sometimes just a switch but no blinking or double page flashing, loader looks good, slow to rotate
  • Kindle Fire - Smooth fades, loader looks good and is positioned correctly
  • iPad1 (iOS5) - Super smooth fades, loader looks good but doesn't actually spin
  • iPhone 4S (iOS5) - Best fades, but the scroll jump to top and restore position is disruptive/blinky b/c of timing. Loader not showing - positioning issue?
  • BB7 - Smooth fades, slight hiccup at the end of the fade in. Not seeing the loader.
  • WebOS 1.4 - Fades only partially happen but feels fast and loader looks good, just not always positioned correctly
  • Firefox Mobile 9 - No transitions (we don't have -moz rules yet) but pages nav quickly
  • Opera Mobile 11.5 - No transitions (we don't have -o rules yet) but pages nav quickly
  • UC Web - Pages have a native slide transition, can't see loader but it's snappy overall
@scottjehl
Contributor

Hey Todd!
Okay, here's an update on the fade-out-in-transition branch.

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.
The new sequence goes like this:

  1. Cue loader
  2. Fade out "from" page, remove active page class
  3. Show the "to" page by adding the active page class
  4. Set focus to the "to" page
  5. Immediately scroll to the final desired location on the "to" page, which is 0 by default, but may be a remembered scroll distance if returning to that page
  6. Cue the fade-in transition on the "to" page
  7. once completed, the transition returns its promise for further external scripting.

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:
http://filamentgroup.com/tests/jqm-fade-out-in/

shortened: http://bit.ly/sa6Z4B

@staabm
Contributor
staabm commented Dec 30, 2011

doesn't belong to this topic, but on ios5 the fixed toolbar in your snapshot does not work properly. the footer toolbar appears and disappear several times in a second.

@scottjehl
Contributor

Thanks Markus. We'll be merging in another branch (css-fixed) for that,
which should do what you're expecting.

On Fri, Dec 30, 2011 at 6:53 PM, Markus Staab <
reply@reply.github.com

wrote:

doesn't belong to this topic, but on ios5 the fixed toolbar in your
snapshot does not work properly. the footer toolbar appears and disappear
several times in a second.


Reply to this email directly or view it on GitHub:
#3217 (comment)

@toddparker
Contributor

This is looking great on all my test devices. No blinks in Android (even Honeycomb). Feels fast and in control. Updated the test page from above:
http://filamentgroup.com/tests/jqm-fade-out-in/
shortened: http://bit.ly/sa6Z4B

@tehraven

@toddparker

"Slide" is now a bit wierd on my phone on your demo.
http://filamentgroup.com/tests/jqm-fade-out-in/docs/pages/page-transitions.html

Hit the "slide" button -- The page slides left, then you see an entire blank page which also slides left, then you see the content of
the dialog.

Additionally, the "pop" button causes no effect to occur whatsoever.

Android 2.3.7 on the G2x

@toddparker
Contributor

Just committed an update to this branch to add -moz keyframe rules. Will probably need refinement.

@toddparker
Contributor

@tehraven - Sorry, forgot to mention that the OTHER transitons in that branch are wonky right now because the new fade requires different JS logic and sequences from the older transitons. Just click around and ignore the other transitions for now.

@staabm
Contributor
staabm commented Dec 30, 2011

@toddparker when browsing through the demo you posted, the loader doesn't disappear after navigation on ios5 with ipad2

@staabm
Contributor
staabm commented Dec 30, 2011

Hmm seems to happen when browsing via gsm/edge and fast clicking several links before the initial load finishes.

@toddparker
Contributor

@staabm Well, just stop clicking so fast :) We're going to keep refining how we handle clicks after a request starts to avoid issues. Currently we prevent user interaction but we're trying to let people click links after the loader starts but that requires a bit more finesse.

@staabm
Contributor
staabm commented Dec 30, 2011

Thanks for pointing out this workarround ;-)

@offsky
offsky commented Dec 30, 2011

Could we please tag this as version 1.0.1 or maybe create a new release 1.0.2 for it? In my opinion, anything built on the 1.0 library is unsuitable for production because of this issue, and it would be nice to have an official resolution on this before we begin work on all the exciting fancy stuff that 1.1 has in store for us.

@Wilto
Contributor
Wilto commented Dec 30, 2011

@offsky Please keep in mind that the default transitions can be changed/disabled completely if you feel they’re unsuitable for your project. Discounting the whole of the library due to page transitions—which are well beyond expected behavior on the web—is kind of a stretch.

@offsky
offsky commented Dec 30, 2011

Dont get me wrong, I think the whole library is great. I have spent several hundred hours building my application on top of it. My goal is to use phone gap to create a "native" app, so while the blinky transitions may be on-par with what the web already provides, they are sub-par when compared to native apps. When I had tried to completely disable transitions in the past, I was still left with some scrolling and blinking, but that was in beta, so I'll give it a try again with 1.0. I still argue that getting transitions fixed is more important than making new widgets. I would like to see this fixed before 1.1 is released.

@karolyi
karolyi commented Dec 30, 2011

@toddparker: Hello, Nexus S with ICS 4.0.3 here, I've come from the jQuery forums.

Tried your last url, but transitions are still slow, sometimes the loader and the page loading hangs, but after all, that seems a little better as it originally was. However, you might know that Google already halted the ICS distribution process to Nexus S devices due to user claims of battery draining, and i can confirm that too. I was one of the 'lucky' guys who had this update, and now I may only rarely disconnect my phone from the charger. What even worse is, Google isn't telling us anything about the repair process, so all we can now do is wait.

What i wanted to tell with that, it may be possible that it will get better, when the official Android fix (if ever) is out.

Cheers,
Laszlo

@toddparker
Contributor

@offsky Getting things like transitions and fixed toolbars sorted is our primary focus for 1.1 for sure. Even though the latest branch just looks like we switched to a fade transition, we actually had to completely re-write all our page transition JS logic to support this so now that this is in decent shape, we need to figure out how to deal with our previous set of transitions because they require different logic and won't be as "fixable" due to the fact that we can't effectively hide the scrolling we need to do so that is going to take some time to iron out.

The good news is that for these two key items, I think we've arrived at a great standards-based approach that seems to check out everywhere. Just be patient as we work through all the details. We were doing basic R&D just last week on what approach to take on transitions.

@karolyi That is really disappointing to hear. I'd like to think that Google is working on an update to improve transition support because if this new style isn't fast and smooth, there's pretty much nothing else we can take away to make this easier on the rendering engine. This looks smooth in Android 2.1 so if 4.0 is so choppy, something is seriously wrong. I know they have re-written how they render in 4.0 so I can see that there will be setbacks, but this is unacceptable. I hope we don't have to get to the point where we surface a way to exclude ICS from transitions, but if the browser is this bad, I rather do that than have people disable transitions to everyone else because lowest common denominator isn't the way. Anyone have a device that shipped with ICS to see if it's any better?

@toddparker
Contributor

Interesting - Joe McCann has a Galaxy Nexus with 4.0 and reports the new transitions are solid. Maybe this is an issue with the ICS upgrade Google pulled: https://twitter.com/#!/joemccann/status/152831935146762241

Whew (tentatively). I've also heard a second twitter confirmation that this looks good on a Galaxy Nexus running 4.0 so I think the issues are with the update.

@Robbes
Robbes commented Jan 2, 2012

@tehraven @toddparker I had the same problem, but had it in all version up from jqm 1.0b+

  • If the target sliding page holds a listview with has thumbnails, and was not previeusly visited, the target page slides left, blank page slides in, and then afterwards that target blinks in place over the blank page.
  • If the page was revisited everything works fine (and a bit faster)

I use iPhone4, iOS 5. I run the app from homescreen, Images/files stored in manifest cache local.

@EdwardIII

I'm still experiencing a flicker using this branch on Android 2.3.7 (cyanogen). When using the fade transition, the transition completes, the new page loads, then the old page content flickers for a fraction of the second after the transition completes.

Slide transition seems to fare even worse, effect isn't visible at all - both old and new content coexist for a moment before visually jumping to the next page.

Is there a temporary workaround for this issue other than disabling for all android devices?

UPDATE
That was based on the branch new-transitions.
Tested again on the branch new-transitions-c and it worked on my device+site.

UPDATE 2
Still flickers on Android 2.3.3 alternative test device (Samsung GT-I9100 / Galaxy S II).

@scottjehl
Contributor

Okay, here's a dev update on the transitions rewrite (fade-out-in-transition branch).

The preview URL is updated here: http://filamentgroup.com/tests/jqm-fade-out-in/docs/pages/page-transitions.html

Please clear your cache before testing, a lot has changed.

Here's an overview.

  • The new out-in transition handler is now the default, and it handles both "none" and animated transitions. This means there's no longer a separate "none" handler, which is probably good because there was a lot of overlap between it and the out-in handler when they were separate. On the downside, the combined handler is slightly heavier than the "none" handler was by itself, so those using no transitions at all will have slightly more code than they need (maybe 20 lines uncompressed). We can continue to monitor this to see if it's a good idea for most end users, or if we need to rethink the handler tie-in so that the none handler can be used as a foundation for more complex animation handlers. Those using transitions will save a bit of code as it is now.
  • The default transition handler lives in "jquery.mobile.transition.js", rather than in navigation.js. It is required unless another (custom) transition handler is provided. I think keeping it external is nice, as it provides a good model for writing a custom handler, and it can be removed entirely if it's not needed. Any problems with keeping it external?
  • We've created some simplified fallback transitions for non-3d transform supporting browsers (with an emphasis on better transitions in Android LTE 2.3), and they're delivered via a new class "ui-unsupported-csstransform3d"), which is added after a 3D transform feature test. The fallback transitions are there for Slide, Pop, and Flip. These fallback versions tend to omit opacity changes when other properties (such as scale, or offsets) are being transitioned, and that seems to provide smoother, and less blinky transitions on Android. I should note that we are using this class in some instances to provide fallback versions of transitions that did not use 3D at all to begin with, as it appears to be a convenient mechanism for targeting browsers that generally have trouble with complex transitions. As a result, some old-yet-capable browsers may end up with a simplified fallback transition, but the difference is minor, and 3D support is future-friendly. We're open to suggestions for an alternate approach, but so far it seems this will be a worthwhile compromise.
  • I've added a new optional, experimental transition called "rotate". It might be a little silly, but perhaps it'll lead to something interesting. Feedback is very welcome.
  • All CSS for transitions are now split into the separate files, so that they can be included or not as needed. Only Fade (the new default), and Pop will be included in the framework by default. Other optional transitions include slide (left,right,up,down), flip, and a new experimental transition called "rotate". If using the "none" transition type, none of these files are needed (but the JS for the transition handler still is required).
  • I've added a new core option called $.mobile.maxTransitionWidth, which defaults to 1000. The option accepts any number or false value. If it's not false, the handler will use a "none" transition when the window width is wider than the specified value. This is useful because transitions get very wonky on wider screens.
  • I've reinstated a full FLIP transition for 3D supporting browsers, which flips the FROM page 90 degrees, scrills, then flips the TO page in from 90 to 0. I think it looks a bit more like a flip than our previous flip-then-fade-in transition in this branch. Please let me know what you think.
  • Cool news! Using the new transition handler, the address bar no longer drops down during transitions in iOS - woohoo! This is something we tried to do a number of different ways with the old handler, and never had any luck unless we used virtual click, which we deemed too risky for primary navigation handling (click target problems in Android).
  • I've updated the docs page to describe the new default transition handler, but the CSS examples for creating a custom transition contain the old "slide" handler CSS. I'm not sure what to do about this. On one hand, this CSS will certainly work fine, but it won't look very nice since the handler now works sequentially, sliding in each page on a queue. Our new slide CSS slides one page and fades the other, but as a result, the code is really complicated to show, especially now that we are sending different transitions to non-3d supporting browsers (and oftentimes, the original transitions have no 3d usage in the first place, making them even more difficult to justify/explain). Should we just keep it as-is? I'm leaning towards yes…
  • I've cleaned up some redundant CSS between non-3d and 3d supporting rules, taking more advantage of the cascade where possible. I also removed a number of z-index rules that no longer apply now that our pages never stack during transitions.

Question for testers:

  • We're debating whether all the fallback transitions should simply be "fade" (or another optional named transition) for non-3D browsers, as the fallbacks for slide and pop are quite heavy in CSS, and may not be all that smooth anyway. Please weigh in here, we may just ditch this idea and programmatically opt-out non-3d browsers to "fade", which would save a lot of code weight as well.

Some outstanding issues I'm working on:

  • I need to add some unit tests for any new code, or changes to the code, and test that everything is still passing where it should.
  • We're considering changing the way dialogs transition in so that the page overlay portion appears immediately, and only the dialog box performs the transition. This provides a nicer effect, but how the code needs to be forked to allow for this is yet to be determined.
  • a few more things I'll remember shortly :)

Thanks!!

@scottjehl
Contributor

Just remembered another one...
Currently, the slide-LR and up-down transitions have a different sequence for which page slides and which page fades. Should we standardize on one way? If so, I think I prefer the way the up-down transitions work, where the page you click fades out and the new one slides in.

@toddparker
Contributor

I spent the day applying the new "ui-unsupported-csstransform3d" class for excluding non-3d devices to slide and pop. These now work and avoid the odd shadow/opacity issue for the most part, but I noticed this cropped up periodically after finishing pop so maybe I missed an opacity somewhere.

After doing all this work, I'm not sure that the quality of these in Android are worth it. The slide up/down will skip the animation randomly so they sometimes jump into place and overall, they are better but still not smooth.

Sort of wondering if we should refine this a bit then decide whether to simply move all transitions to fade if the 3D test fails. It would be less code and probably a better Android experience.

Playbook passes the 3D test and looks good so it's not just iOS that will see the good transitions if we decide to stick with a simple fade across the board for older Android builds. We need to test to see if ICS passes the 3D test and does the flip (guessing it does, supposed to support this).

Anyway, that's where I am. Once you finish the rest up tonight we can do a round if testing and decide.

@toddparker
Contributor

These updates look great Scott. Thanks for cleaning up my CSS, I knew it needed some love. My comments above were from before your post so sorry for the odd sequence.

  • I agree that the slides should have similar sequences but maybe we should try both ways for each and either pick the best or even make both available. For example, we could have a slide-fade transition set and a fade-slide set where the sequence is consistent across slide, up, down becuase both may end up being legit.
  • It's great the address bar stays hidden on the buttons on that page, but when I press the "I like it" dialog button, the URL still drops. Any ideas why that still triggers it?
  • The rotate is cool,but I wonder if there are some even slicker and complex animations we could try now that we can target these to more capable platforms? Some 3D effects that really push things. Looking for some examples to model like http://persistent.info/webkit/flipboard/flipboard.html or * http://developer.apple.com/safaridemos/showcase/transitions/
  • Flip looks awesome now
  • Sort of on the fence on the transition handler docs. I'd almost rather spend time explaining how to write your own new CSS transitions while using our handler - how to think about how we slot in the scrolling, now to exclude non-3D browsers, etc.
  • Really thinking that non-3D browsers will be better off with just fade for all transitions (cough, cough, Android), but I'd like to hear from Android testers if any of the non-fade transitions look acceptable first because we can pick and choose which to attempt. Please let us know because we're already being as easy on Android as possible so if the slide/pop transitions still look chuggy/blinky downgrading all transitions to a simple fade still may be our best option. Also, please confirm that the simple fade looks ok.
@staabm
Contributor
staabm commented Jan 5, 2012

don't know if it matters... when having a look with a desktop browser on your demo-transition page, there will be no transitions at all (tested on ff10 and chrome16).

@Robbes
Robbes commented Jan 5, 2012

@staabm Did you resize your screen to less then 1000px width as mentioned in posts above?

In my Chrome it all worked nice with a small windows, and using a bigger windows it looks all like the none-transition is used. Looks nice!

@toddparker
Contributor

@staabm - If you make your browser window below 1,000 pixels, you'll see animations. See Scott's note about the feature we just added to turn off transitions above a certain window width. On larger screens, the transtions can be very distracting and/or slow, especially on tabets so this is a new config feature.

@dbrouard
dbrouard commented Jan 5, 2012

Hi all, first of all, thank you so much for this work.

I'm developing a jquerymobile app and I've been force to use jquery-ui because of this issue. I would like to test these changes in my app, could it be possible to have a packed testing library file?

@staabm
Contributor
staabm commented Jan 5, 2012

@toddparker @Robbes thanks for the hint. in chrome16 it works in a window which is smaller than 1000px. FF10 does not shown animations with such a smaller window, but I am not aware if the firefox supports those transitions at all.

@rbdcti
Contributor
rbdcti commented Jan 5, 2012

@dbrouard: You can clone the fade-out-in-transition branch to your computer, then run the 'make' command. This will generate minified versions of the css and js assets (if that's what you mean by "packed testing library file"). More info on building from source is available on the jquery-mobile github home page.

@dbrouard
dbrouard commented Jan 5, 2012

@rbdrbd thanks!

@offsky
offsky commented Jan 5, 2012

Tested on Kindle Fire.

Fade and slide work great. Pop, slideup and slidedown work great on the forwards direction, but when pressing "I like it" it goes back without any transition at all. Flip doesnt work, just defaults to fade. Rotate works in both directions, but the animation stutters.

Its a big improvement over the 1.0 code, so good job!

@toddparker
Contributor

A few important notes about the new transitions:

  • We've very happy with the quality of the new transitions and how we've concealed the page scrolling by moving that later in the sequence (after the fade out) so these now feel smooth, with no odd blinking or scrolling seen on most platforms (see exception below)
  • We hope to land the final version of both the new transitions + fixed toolbars next week for final refinement/testing and inclusion in 1.1 slated for February.
  • After reviewing the 2D "optimized" transitions, we still don't think performance is good enough and it sounds like other are seeing similar results. We're spoon feeding Android the simplest transitions possible (animating a single property only, no fades, longer duration for more frames) and they still skip the transition randomly, drop tons of frames, and generally still look janky, blinky and out of control. This leaves us with no choice...
  • The decision we just made is that we're going to use our 3D feature test to degrade all non-3D supporting browsers to the simple, fast and reliable fade transition for ALL transitions via JS and remove all the 2D exclusion CSS cruft we added in the demo above.
  • This means that Android 2.1, 2.2, and 2.3 will only have a fade transition, regardless of the transition specified, but the experience will be smooth, flicker-free, and in control which is paramount. Android is simply not capable of page-level transitions. It might be fine for animating smaller elements on the screen, but animating pages is very taxing.
  • Android 3.x (Honeycomb) and 4.0 (ICS) support 3D so these will get the full set of transitions. Note that 3.x has horrible transition performance but luckily this has ~1% of the Android market. 4.0 is supposed to be quite a bit better (jury's still out). We're not going to do anything to exclude these versions right now so it's up to Google to step it up.
  • We're looking at adding a new transition or two that are super slick for 3D supporting devices like iOS and the Playbook. Looking for inspiration/ideas of cool page transitions.

As always, we welcome your input on this!

@Robbes
Robbes commented Jan 8, 2012

I like the improved transitions: They are more responsive and smooth on my iPhone 4 with iOS5! I was however wondering if the slide (LR, UD, etc.) transition will be changing further, or if it will stay like it is (combined with fade). I kinda find the slide-old-page-out and fade-in-new-page not the most slick looking way of sliding pages, since a full background is visible in between the slide and the fade-in. Why not put the new page in place and leave out the whole fading, so the old page slides off and the new page gets revealed? Or, the new pages slides over the old one.

I understand that a lot of these transitions where tested and a lot of thought went into them. I'm not sure if I’ve read all about these transitions in this issue posting, but as I understand there are other transitions in testing as well. Can someone give an overview of what variants are in dev/testing? Would it be an idea that if the fade transition becomes default for Andriod, that there are more options now open for the slide transition to become even better for all 'better supporting' platforms?

@toddparker
Contributor

@Robbes - Yeah, we agree that the slide + fade isn't ideal, but one of the hard constraints is that we need to scroll the viewport to deal with the fact the each page may be very different heights and you may already be scrolled down. In 1.0, you saw the page fly by as we scrolled around but in the re-think we always fade to a black page momentarily to provide a clean place to scroll so this is sort of the best we can do given the scrolling contraint.

At the moment, we've been focusing on getting the new transitions built and updating all the tests, but we do plan on adding at least one or two new transitions for 1.1. Now that we're not as limited by Android 2.x performance, we can do some potentially cooler transitions that still work with our need to scroll the viewport.

You can preview the latest build here (updated a few minutes ago) and this includes a new "flow" transition that looks sort fo like the iOS web tab switcher -- make sure your browser is less than 1,000 pixels wide to view these.We're also working on a WP7 Metro-esque transition that does a flip but with the pivot in the left edge. Looking for ideas!
http://filamentgroup.com/tests/jqm-fade-out-in/docs/pages/page-transitions.html

@toddparker
Contributor

Here is the latest version of transitions and include two new types:
http://jquerymobile.com/branches/fade-out-in-transition/docs/pages/page-transitions.html

For reference, the last version of this branch that still allowed non-3D browsers like Android 2.x to use all transition types is here so you can compare how bad these perform and hopefully agree that falling back to fade is a good idea:
http://filamentgroup.com/tests/jqm-fade-out-in-no-3d/docs/pages/page-transitions.html

NOTE: We have all transitions off if you view on a wider than 1000px width screen. We always did this in the docs because a slide or flip at that size is both alarming and not very performant. This is configurable, but be aware if you see nothing at all this may be the case.

@tehraven
tehraven commented Jan 9, 2012

@toddparker The current fade-out-in-transition docs do not render any effect either on an Android or Webkit browser. Is this intentional? I can't see the desired effects whatsoever right now.

@jblas
Contributor
jblas commented Jan 9, 2012

@tehraven

If your browser viewport is greater than 1024 pixels no transitions are used.

@toddparker
Contributor

We have a 1000px width cutoff where we shut off transitions (configurable) because it feels better with these off. Are you looking at a wide width?

PS - I updated my message above to note this.

@tehraven
tehraven commented Jan 9, 2012

Disregard my latest. I should keep up to you, @toddparker. You update this very quickly (good job!).

All is well over here. I hope more can come from Android 2.* in the future.

@staabm
Contributor
staabm commented Jan 10, 2012

Branch: http://jquerymobile.com/branches/fade-out-in-transition/docs/pages/page-transitions.html
On FF10 it seems all transitions look similar...? all seem to be fade transitions... is FF10 blacklisted again so fallback is used?

Branch: http://filamentgroup.com/tests/jqm-fade-out-in-no-3d/docs/pages/page-transitions.html#&ui-state=dialog
all transitions work on FF10 but pop transitions leads to an empty grey page.

@toddparker
Contributor

Note: we've created a new branch with the latest transitions "out-in-transition" is where we're doing final work before pushing to master.

Preview:
http://jquerymobile.com/branches/out-in-transition/docs/pages/page-transitions.html

We need to back port some of the docs changes and new transitions into this branch today. All unit tests are now passign so we're getting close to landing this in master.

@tehraven

@toddparker After review, I see an issue with turning off animations for screens wider than 1000 pixels. Some new tablets come default with resolutions of 1024 and 1280 (Asus Transformer Prime is 1280x800, iPad2 is 1024x768).

$( window ).width() > $.mobile.maxTransitionWidth

Clearly looks like these new powerful tablets are going to be left in the dark. Thoughts?

@toddparker
Contributor

@tehraven Sure, choosing 1,000 pixels wasn't accidental. We found that having transitions off at 1,024 (landscape) looks quite a bit better/faster. We're open to tweaking the default to 1,024 so these are on in both orientations but transitions like slide or flip feel really jarring to me with that many pixels in motion. Fiddle with that threshold on your own and see what you think. One side benefit: Android 3.0 is a train wreck with transitions so if you switch to landscape, things improve dramatically in the new transitions because we switch to "none" transitions.

As an aside, we've had this rule in our demos & docs pretty much from the beginning. We switch to fade at >600px and none at 1,000px but I decided to move this into the library itself as a config option instead of a customization in the docs.js because it's useful and people would see a very different thing between the docs and a "stock" jQM site.

@toddparker
Contributor

@staabm - Does Firefox support 3D transforms? If not, it will see the fallback versions (fade by default).

@staabm
Contributor
staabm commented Jan 11, 2012

Tested on http://jquerymobile.com/branches/out-in-transition/docs/pages/page-transitions.html:

@toddparker hmmm seems FF10 supports only simple transitions.

In Chrome17 there are some rendering issues in the dialog which opens up
http://imageshack.us/photo/my-images/716/chrome17.png/

@scottjehl
Contributor

Hey All.
Here's the rundown of where things stand with the transitions update branch. Some of the important fixes are in now, and outlined below. I think it's ready to land today or tomorrow - the question is how best to do so. We can discuss that today.

3D Transform Test:

Sounds like it's only working for the webkits. We'll take a look at what we can do to get Firefox 10 included.

Unit Tests: 

All Passing - navigation test suite and helpers have been rewritten to match the new transition handler.

New Unit Tests: 

I added tests for the new maxTransitionWidth option. Still need tests for the dialog custom transition (under dialog tests, ideally), and better coverage of the nav sequence, but all that can come post-merge into master.

Special Case for Dialog Transitions:

The gist of the change is that I modified the dialog plugin so that on pagebeforeshow, the dialog's overlay theme class is added to the page container in addition to the page itself. On pagehide, that theme class is removed. Then I tweaked the CSS so that the dialog's page div (the overlay part) has no background at all, and it shows through to the now-themed page container. As a result, the inset dialog box itself is the only part that visually animates.

Feels pretty nice to me. Check out the branch and let me know what you think. 

Keeping the Address Bar Hidden on iOS during all transitions:

Now mostly fixed! :)

I did some testing to figure out why it is that most page transitions cause the address bar to drop, yet the ones on our transitions page do not (but the custom "back" link on the dialog still does). Here's what I found, and the fix I've implemented (comments welcome).

Our transitions page uses a multipage dialog (a local div instead of an external page). As a result, the link HREFs in the examples are all #dialog. I've found that in binding to click (instead of a touch event), as we do, on a link with a non-hash HREF will always cause the address bar to hide. The links on our transitions page are all hash-based, so they don't cause it to drop down, but most other links in the docs reference external hrefs.

In an attempt to work around this, I found a way to trick iOS into thinking a link is local during the click, without interfering with the click handling:

On touchend (or vclick in our case), I'm caching the link's HREF value to data and temporarily setting it as "#". Then in our click handler, if a link has a data-href stored, I set the href attribute back to that stored value. This quick toggle prevents the address bar from showing up on any click.

A known caveat: The address bar will still likely drop down when you click the browser's back button. The only time the back button will not drop the address bar  appears to be when the back button does not trigger a pushstate operation - so pushstate would either have to be disabled, or the page would have to be local (multipage), or the page would need to be a dialog (since then going back would only be a hash change). Still, progress.

Prevent blink on iOS when scrolled down more than 1000px: 

Still haven't gotten around to working on it. This can wait until after merge to Master I think.

Code Integrity after rebase: 

I'm nervous this branch didn't cleanly rebase from master, after the massive amount of merge conflicts I had to manually resolve. 

@toddparker, what do you think? If you're concerned as well, I'm thinking I should make a new temporary branch where I can just run a diff between this branch and master and figure out the few big commits that need to happen in some large organized chunks (one for the new transitions handler, one for unit tests, one for the new CSS and JS for transitions, etc).

@masteinhauser

I just wanted to chime back in here as I have been watching the thread. The recent improvements in this last push with the dialog and how transitions look are superb. The recent work on all of this looks fantastic on my iOS 5 iPhone 4 and now on ICS on my Transformer Prime. The ICS upgrade for my Prime helped incredibly as the 3.2 browser was horrid with transitions but everything is extremely smooth now. I have yet to test out personally on an iPad but will post back if I find any issues.

The only perceived issue I have is how long the actual transitions take. I'm not sure if that's a hardcoded value or something simply due to hardware. They still look and operate great, but they "feel" a bit slow.

Overall, I'm extremely excited when this gets pushed to master so I can integrate it with the app I'm working on now. Great work All!

@toddparker
Contributor

@masteinhauser - thanks for the feedback. When you say the transitons feel a bit slow, is this across all platforms or just one one like ICS (I've seen odd delays in transitions there). In general, these are a shorter duration than in 1.0.

@masteinhauser

@toddparker Good question. It definitely feels slower on ICS than on my iPhone 4. The iPhone 4 doesn't feel bad compared to ICS, though they both linger a bit when tapping a button. I did notice they are faster than 1.0 which is a very nice change.

The lingering isn't an issue on iOS, but Android seems like it doesn't do a good job of loading the graphics library into memory. So, I'm not certain there is much you can actually do with that.

@toddparker
Contributor

@masteinhauser Unfortunately, I we still don't have a ICS device in the ab and the only one we have access to on the team is not a legit upgrade. In that device, I saw oddly long delays before starting the transition, then a pause in the middle when we scroll. Are you seeing that? Did you device ship with ICS?

@samatjain
Contributor

@scottjehl

3D Transform Test:

Sounds like it's only working for the webkits. We'll take a look at what we can do to get Firefox 10 included.

Where does this happen, exactly?

On Firefox Aurora 11, in which the fancy transitions do not work, $.support.cssTransform3d is False, and $.support.cssTransitions is True.

On Chrome 17 Beta, in which fancy transitions do work, both these are reported the same.

This implies the detection code in js/jquery.mobile.support.js isn't the problem.

@masteinhauser

@toddparker That is definitely understandable. This did not specifically ship with ICS, it shipped with 3.2 but I did get the official ICS upgrade from ASUS two days ago. That is a very good description of what I am seeing as it is difficult to put into words without knowing what is happening behind the scenes. I'm definitely open to testing and helping out how I can.

@Dragooon

Perhaps I'd also provide some feedback here, I'm sorry if some of this has been stated before, I only managed to read a few key comments in order to understand what's going on.

Transitions in iPad 2 landscape is disabled, but honestly they shouldn't. iPad 2 under portrait mode handles them just fine, I don't think it should have much problem in landscape. Perhaps it's due to the 1000px limit which should be raised a bit to accomodate some tablets?

Transitions in ICS themselves are smooth, but there's a delay in them being started. Perhaps a bit slower than they should be, but they are smooth and don't blink like current 1.0 release. I'm not using a legitimate ICS device, but I don't think that should be a problem since the ICS release for my device is fairly complete with full HW acceleration and composition and this happens in both of my test devices.

@toddparker
Contributor

Here is the latest version, be interested to hear how it's working. We're close to landing this on master and can refine a bit from there.
http://jquerymobile.com/branches/out-in-transition/docs/pages/page-transitions.html

  • We re-vamped this page to show the difference between the new dialog animation and a normal page. Dialogs look slick now that they are visually decoupled from the background.
  • We're working on tracking down some of the FF10 oddness, getting closer there.
  • Honeycomb (3.0) passes the 3D test and generally crashes and burns, hoping a lot of these devices will get a 4.0 upgrade because 3.0 is a complete mess
  • Android 4.0 seems to work fairly well if it ships on the device (Galaxy Nexus) but if horrible if you upgrade (Nexus S) which explains why Samsung announced that a 4.0 upgrade will not happen. Sounds like ICS requires a fast processor to run smoothly so if you upgraded early or have a bootleg upgrade, expect poor performance, not sure what we can do to fix Google's mess here.

Looking forward to hearing reports from the field on this.

@Dragooon

Transitions on ICS on my Galaxy Note are fairly good now, but ICS on my Galaxy S is fairly unstable, it seems that out transitions are fine but in transitions are having a delay. On my iPad 2 they're flawless.

@toddparker
Contributor

From what we're seeing, the majority of 3.0 (Honeycomb) devices will be eligible for 4.0 (ICS) so our hope is that 3.0's already tiny market share will shrink to a point where it's poor performance won't be significant.

For example, both our test 3.0 tablets (XOOM and Galaxy Tab 10.1) will be upgraded to ICS soon:
http://www.motorola.com/blog/2011/12/07/motorola-update-on-ice-cream-sandwich/
http://androidadvices.com/samsung-confirms-ics-40-galaxy-s2-note-tab-101-tab-77/

So our transition strategy for Android is looking like this: exclude 1-2.x, hope 3.x goes away, and pray that 4.0 is actually decent. Sort of sad, but given the state of things, this seems like the best approach.

@toddparker
Contributor

Hooray - the new transitions have landed on master:
http://jquerymobile.com/test/docs/pages/page-transitions.html

we'll keep refining, but we're close now. Onto landing fixed headers...

@staabm
Contributor
staabm commented Jan 12, 2012

It looks perfect on ipad2 with ios5.0.1

@masteinhauser

Looks very good on ICS on my Prime. Awesome work! :)

@woutervanwijk

Great work! Three things though:

  • on the Turn transition, when returing to the last page, the animation stops for a small moment. A detail, but still...
  • the other one is more important imho: before the animation, the page turns gray. That's not very beautiful, animation-wise. Isn't it possible to make that more beautiful?
  • After I press a button, it takes a while before the animation kicks in. That's a pity, because it makes the user wait.
    Otherwise great work, much better than it was!!!!
@woutervanwijk

I'm on ipad 2, ios5 btw

@tehraven

Seems a bit smoother on most devices, and I think overall, it improves the animations on my G2x (rooted with CM7), but I'm not sure it's perfect yet (or that it ever can be...). Here's what I see:

Video record (Bad quality, but good frame rate which you can see the "jumping" of animations): http://www.youtube.com/watch?v=vBbyRry9Sxo (The video is really poor -- sorry! Hopefully it at least shows you the flashes I reference below..).

Flip, Turn, Flow and Slide were all jumpy (seemed like it was running in a low frame rate). Also, when returning back to the page from the dialog/page, the additional "jump" from the top to the "last scroll position" is slow enough to be a bit irritating over time.

And then we get to Slides... They all seemed to cause multiple flashes before any animation even starts. Click a button, flash, flash, animation start, animation end. (Note that the video is poor -- when the animation ends, the recording phone has issues with auto-contrast -- that is not the flash I'm referencing, of course).

@karol-f
karol-f commented Jan 13, 2012

Hi, I just want to tell you that you guys did tremendous job. Of course transitions aren't perfect but it's much better than it was. Transitions was a deal breaker for many - thanks again.

BTW If css-fixed (fixed toolbars) will be merged to master as well, the next release of JQM will be awsome :)

@scottjehl
Contributor

Thanks a lot Karol, it was a lot of work, so it's great to hear that it was worthwhile :)

I'm working on merging CSS-Fixed as we speak!

On Jan 13, 2012, at 3:18 PM, Karol Fabjańczuk wrote:

Hi, I just want to tell you that you guys did tremendous job. Of course transitions aren't perfect but it's much better than it was. Transitions was a deal breaker for many - thanks again.

BTW If css-fixed (fixed toolbars) will be merged to master as well, the next release of JQM will be awsome :)


Reply to this email directly or view it on GitHub:
#3217 (comment)

@rbdcti
Contributor
rbdcti commented Jan 13, 2012

Hey guys. Once again thanks for all of the great work you've been doing. Just wanted to give a heads up: I tried out the latest master yesterday afternoon with my app and noticed that several things were broken (over a master I'm using from about 2 weeks ago):

  • I have a few buttons in my top header (right hand side): Those were no longer there.
  • I use a persistent footer with a navbar with icons. Each icon is a regular old anchor link to a specific page. Clicking on these no longer worked.
  • I think there were one or two other minor things..I didn't get that far in my testing because of these two ones though...that last one especially made the app pretty unusable.

I just chalked these up to some merge-related instability that will be fixed once the regression tests are fully run again, but I wanted to make you guys aware of it.

@toddparker
Contributor

@rbdrbd - Thanks for reporting. Would you mind posting each as separate issues with a test page linking to latest? Sort of surprising that this would affect toolbar buttons or links so I just want to make sure we track these down.

@rbdcti
Contributor
rbdcti commented Jan 13, 2012

@toddparker: Sure thing. I did download and compile the newest master and jquery.mobile.js won't parse out of the box. Made an issue #3429 for it. I'll make cases for these other issues once that issue is resolved.

@rbdcti
Contributor
rbdcti commented Jan 14, 2012

@toddparker as an update, the issue with the page transitions not working actually seems to be because I was using a custom themeroller theme (seems the output themeroller produces breaks transitions... I made issue #3434 before I realized themeroller had its own project... that issue is over at jquery/themeroller.jquerymobile.com#67). I include a testcase.

The temp fix seems to be to just include the JQM main css file before the custom theme one (where normally I was including the custom theme css, followed by the .structure.css file, as the instructions dictated). But since I'm guessing this new page transitions code broke this between JQM and themeroller, I wanted to mention this here on this ticket so that those subscribed and browsing it were aware of this issue, if they are using custom themes.

If you guys don't have any testcases using a custom themeroller theme, you may want to look into that.

@pkoretic

is it just me or somebody else is having really problems with these new transitions
http://jquerymobile.com/test/docs/pages/page-transitions.html

all of them make many problems (so they look like everything else but the animations) in latest chrome on my desktop (it works super great with older iterations) and on my android 2.3
also, vertical scrollbars appear when you open a dialog so i suppose that's a problem too (document height is a few pixels more than it should be)

@dcarrith
Contributor

Sorry for the crazy long posts. But, I've been watching the progress on the blinky transitions for months now and wanted to finally offer some feedback.

Thanks for all the great work you've put into JQM to get it to where it's at today. I've built an MPD client (for music streaming / remote control) application with JQM and am thrilled with how it has turned out so far. It's still under development, but I use it as my primary music app to stream my 60 GB MP3 collection to any device anywhere. I'll be releasing the source code soon so other MPD enthusiasts can enjoy the flexibility of MPDTunes. I have some screenshots of the earlier versions posted at www.mpdtunes.com if you want to see how your work has been put to good use.

Now, in response to this "Page transition re-think: Smoother, faster" issue:

I've been doing quite a bit of testing after I pulled down the newest master (after the newest transitions landed on master 2 days ago). I was really hoping that the blinkyness was a thing of the past.

First, here are some of the devices/platforms/browsers I have been testing with:
Kindle Fire (Silk, Dolphin HD, Firefox and Opera Mobile)
HTC Thunderbolt running CM71.1/Gingerbread 2.3.7 (Dolphin HD, Firefox, Opera Mobile, Miren and Stock Android Browser)
iPad 1 with iOS 5 (Safari, Dolphin HD and Opera Mobile)
HP Touchpad that dual boots WebOS 3.0.4 and CM7 alpha 3.5 (so all the normal browsers as well as the standard WebOS browser)
Macbook Pro running OSX 10.6.8 (Safari 5.x, Chrome, Firefox )
PC running Windows 7 (Chrome, Firefox and IE9)
A machine running Ubuntu 10.04 LTS (Chrome and Firefox).

I'm testing with my real music collection. So, the list of artists is 174 in length. My Pearl Jam albums list is about 77 in length. Bob Marley is pretty lengthy as well. So, I consider this to be a real world test of the list performance (and transition performance). I know in the docs section there is a list with 500 or so items, but I'm not sure if that is dynamic or static...I'm guessing static. I'm also wondering if you guys are testing these new transitions with static or dynamic data.

Anyway, I'm sorry to say but I'm even seeing blinkyness in Chrome v16.0.912.63 on OSX. Granted, it's somewhat different than the blinkyness I see with the 1.0 release on Android. But, Chrome running on any desktop (especially OSX) has always been blink-free and just about flawless in every way.

I'm not only seeing blinkyness, but I'm also seeing some strange background color issues on just about every device I've tested. The slideup and slidedown seem to work okay...but I still see some strange background coloration artifacts. Not only that, but the transitions (even the fallback fade transition) seem to degrade after continued back and forth use (as would naturally occur in real-world use of an app such as a music streaming app).

I am also seeing the issue that rbdrbd reported above with the latest master mangling some buttons in the data-role="header" sections. Two of my data-role="button" links are only rendering as a small circle when they should have the words "Repeat" and "Shuffle" on them. I'm also seeing an issue with a footer that has the data-role="footer" attribute. The styled links in the footer also have icons on them. Those are getting a width of about 5-10 pixels rather than 25 or so like it should be. Those are both an anchor tag with class="ui-btn-left ui-btn ui-btn-icon-notext ui-btn-corner-all ui-shadow ui-btn-up-a" as well as data-theme, data-iconpos and data-icon attributes.

On a more positive note, I love the flow transition (it's really slick) but I haven't tried to use it.

@dcarrith
Contributor

I tested my music streaming app in Safari on an iPad 2 running iOS 5.0.1 this morning and it was definitely better than any of the other devices/platforms I've tested on before. I did NOT see the button styling issues like I see on the android devices. Which, by the way...I neglected to mention above...I have not noticed any button styling issues on the desktop browsers....I think it's just on the Android devices I've tested with. The transitions seemed quite a bit better on the iPad 2, but I did still see some issues. One issue in particular is a bit concerning. I've now seen it on a couple devices (iPad 2 included). It seems that if I go back and forth looking at different artists / albums and tracks...eventually, a page of albums or tracks will only load the bottom half of the page. Sometimes, the page just won't load at all and I'll see just the themed background color. I have to go back in browser history and then can usually get to the page I want loaded. Kinda strange. Overall though, the iPad 2 was noticeably better than what I've seen in my testing on other devices.

@dcarrith
Contributor

So, after some more testing, I started noticing some patterns. It seems that a lot of the blinkyness I'm seeing is being caused by the ol' scroll up or down right before the transition. I've noticed when I'm scrolled down in the list of artists, and I select "Pearl Jam" for example, it scrolls all the way back up to the top before transitioning over to list the Pearl Jam albums. I imagine that would get worse the longer the list and the farther down the user is scrolled before selecting a page to transition to. Something else I noticed is that when I go from the list of Pearl Jam albums (for example) back to the list of artists, it tries to scroll the list of albums down to where it expects to have to be after it transitions "Back" to the list of artists (i.e. scroll down to Pearl Jam which is pretty far down). I don't know if those two scenarios are being caused by the same JQM logic, but if we could find some way to hide that pre-transition scrolling...or just turn it off...that would solve a lot of the blinkyness I'm seeing (on all my devices). I would argue that the blinkyness makes it far less usable than if it was to NOT scroll back to the last position on the page. If it's an inseparable choice between those two usability concerns, then I would fix the former. I've been following this issue for a long time and I've read most of the posts that explain why it has to scroll back up to the top before the transition...but there's got to be something we can do to fix it. I say "we" because I'm going to experiment with it a bit.

@BrentHathaway

On a Android 2.3.5 app and web, the old slide looked awesome, and the desktop Windows Chrome version of page-flip looked awesome as well. It will be a little sad to see 2.3.5 get cast into the abyss of fade-only animation.

I think there needs to be a mention when discussing this whether or not the problems lie with app, web, or both.

@scottjehl
Contributor

We're currently looking at why some transitions (or browsers) end up seeing a scroll before the out transition, as it should not occur until the first animation is completed. Suggestions in the code are welcome!

On Jan 16, 2012, at 11:37 PM, Brent Hathaway wrote:

On a Android 2.3.5 app and web, the old slide looked awesome, and the desktop Windows Chrome version of page-flip looked awesome as well. It will be a little sad to see 2.3.5 get cast into the abyss of fade-only animation.

I think there needs to be a mention when discussing this whether or not the problems lie with app, web, or both.


Reply to this email directly or view it on GitHub:
#3217 (comment)

@pkoretic

#3432
that fixed it?

@toddparker
Contributor

@pkora - Seems to have, yes. We also just noticed that the use of the old style fixed headers in our page example on the transition tester was causing Android to go into it's opacity freak out mode. Working on patching up the demo page now, should feel a lot smother on Android. These are all the little things we can tweak to refine this. It's all black magic from here on out.

@toddparker
Contributor

@pkora - Realize that on Android 2.x, we're only using the fade transition regardless of the transition specified because the performance of this platform is abysmal with CSS transforms. But the height tweak should fix the scrollbar you mentioned and the other fix we're working on now will make the fade smoother because Android doesn't go into it's bizzaro opacity bugginess.

@dcarrith _ I appreciate the extensive testing. If you are serving up listviews with 300-500 items, that is going to be very heavy for most mobile devices which will make page init slow, transitions buggy and will probably cause crashing on all but the most modern phones. It would make a lot of sense of paginate to around 100 items for best performance or just load up the first 30-50, then lazy load the rest in as you scroll like the Twitter app. If you test this on smaller pages, do thing look better? We are looking at the scroll jump now because even though it is async, I think when you have a long page the scroll callback isn't really in sync with the rendering so the scroll and transitions are stepping on each other and causing a blink. We're looking at this now too.

@BrentHathaway - The older transitions only looked good on short pages but as soon as we needed to scroll to the top or restore your scroll position, you'd see the page fly by. The bigger issue is with Android'd rendering quality with the slide and pop transitions. I spent a ton of time trying to baby Android and remove anything complex (say moving the x position and fading at the same time) and even when I did that, Android would drop frames horribly and randomly so sometimes you'd see a few frames, other times nothing and it just felt flaky. The new philosophy is that we stick with what is fast and reliable (fade) unless you can prove you're a capable browser. Unfortunately, Android 3.0 still gets passed and doesn't a pretty bad job, even on fade. The jury is still out on 4.0. I tested the latest on a Galaxy Nexus running 4.0.2 yesterday and really didn't see any transitions at all, just a few blinks but others have reported better results. Hoping they improve things in a maintenance release.

@rbdrbd - Thanks again for submitting that issue. We need to get ThemeRoller ready to handle there being two releases (1.0 and 1.1) so this will be addressed by the time we hit 1.1. In the meantime, if you have a custom TR theme, you may need to do a diff with our theme file in master to see what's changed and manually tweak your file. At 1.1, it will be as easy as importing and downloading a 1.1-ready version.

We'll keep updating master with improvements as we go:
http://jquerymobile.com/test/docs/pages/page-transitions.html

@toddparker
Contributor

Just committed: Faster fade in (225ms vs 300) and out (100ms vs 150) to see if this feels snappier.
Try it on the test link above, only affects fade transition.

@tehraven

Nice changes Todd.
On Jan 16, 2012 6:28 PM, "Todd Parker" <
reply@reply.github.com>
wrote:

Just committed: Faster fade in (225ms vs 300) and out (100ms vs 150) to
see if this feels snappier.
Try it on the test link above, only affects fade transition.


Reply to this email directly or view it on GitHub:
#3217 (comment)

@dcarrith
Contributor

@toddparker - thanks for the tips. My list of artists is not quite 300-500, but I'm sure there are plenty of people out there with much larger collections than I have. I'll definitely look into lazy loading as the user scrolls. I wonder if it would be possible to lazy load and "unload" at the same time so that the height of the document is only so large and therefore the scroll back up to the top before the transition would be minimal.

I have tested on smaller pages and it is better, but it does still look blinky (especially on Android). It also seems to depend on the size of the page I'm transitioning to as well as the size of the page I'm transitioning from.

As far as my application in particular is concerned...supporting older devices isn't much of a concern for me since any potential user's device has to be new enough to run an OS and Browser that supports HTML5 audio elements (Gingerbread and above for Android). I'll probably go so far as to highly recommend a 4G capable phone for the best experience. It does fine on 3G...even with a weak signal...but, 4G (on an unlimited plan) is ideal.

Either way, your suggestions could improve the experience even on the fastest device.

@masteinhauser

@toddparker The faster fade feels much better in Chrome 17, and on 4.0.2. If needed, I can probably take a video of different effects to give you feedback on the Prime.

@toddparker
Contributor

@masteinhauser - videos of you clicking thru all the transitions on Androud 4.0.2 would be great. If you want to experiment locally to see if different durations help with smoothness on the 3D transitions, that would be helpful too.

We'll probably end up speeding up most transitions a bit before 1.1. All part of the fine tuning.

@pkoretic

i'm testing it on
http://code.jquery.com/mobile/latest/demos/
opening dialog still shows a vertical scrollbar,
nevertheless, imho width:99.9% is not a valid solution for any bug to fix...
i'm positive that all the problem lies in css3, which is to heavy for android webview when you combine it with animations
http://perfectionkills.com/profiling-css-for-fun-and-profit-optimization-notes/
and this framework (whose name shall not be spoken) is working flawlessly and looking the same in ie7+ and my android tablet/smartphone
http://chrism.dojotoolkit.org/mobile-rc1/release/demos/demos/mobileGallery/demo-iphone.html

this post is also very interesting, it maybe shows how jquery mobile itself needs more optimizations
#3006
i'm sure that data-transition="pop" (my favorite) would work perfectly if css2 was used but since this is not an option
i'll fork git next month and put some things to the test, being smarter with css3 will surely improve performance given the above

@toddparker
Contributor

@pkora If you're not happy with that fix, please do suggest a more valid solution. Re: CSS3, I'm assuming you're referring to our use of CSS gradients, box-shadow, text-shadow and border-radius since there is no CSS2 way to doing transitions. Yes, these do add to the rendering overhead but the alternative is to use a ton of background images which is bandwidth-heavy, non-themable and not really modern practice anymore.

Lastly, the Dojo example you linked to, while nice, has a different set of technical contraints because they (and many other frameworks) rely on a JS-based scroller which gives you fixed toolbars and smooth transitions but at the expense of code weight, performance, compatibility and non-native scrolling physics (all use iOS physics which feel odd on Android, for example). If that tradeoff is preferable, there are a lot of good options to consider. We are very close to achieving both fixed toolbars and smooth transitions without these same drawbacks and we think this is a valuable addition to the range of options available to a developer. If every framework adopted the same technical goals and approach, there would be no real choice.

As always, we welcome pull requests to help us improve and look forward to your input.

@dcarrith
Contributor

I think one of the reasons why I was seeing the new transitions as being so blinky (other than the scrolling before the transition) is because I only had the data-theme="a" set on the data-role="page" div. So, when it was fading in and out, or sliding right and left, the background of the html document was white. I made a change so that the background color of the html document is the same background color as the currently applied swatch and it made the transitions I'm using (slide, fade and flow) look much better. I'm also using slideup and slidedown, but those are applied to data-role="dialog" divs which seem to already set the background color of the html document to match the currently applied theme, so those didn't need fixing in my case. For testing purposes though, it's probably a good idea to have to background color be something that contrasts with the currently applied swatch so that any blinkyness really stands out.

@pkoretic

@toddparker to start with, I apologize if it sound like i was criticizing (jquery mobile is a great library in my opinion, that's why I'm here, trying to help) I was merely pointing to examples
I agree CSS3 is the way to go and I wrote that, I just wanted to say that (as first article showed) you can get same look and quality by being smarter with CSS3 features, even with basic CSS, like having less selectors
text-shadow, box-shadow, linear-gradient, border-radius etc are all expensive, using them less on mobile platforms will provide noticeably better performance - i'm not only referring to that article, I think we all know that
in the example there is 171ms overhead on simple button, using only relevant features we can get the same look with less overhead
Anyway, I don't have time for discussion, I'll be back in few weeks and will provide real world examples of what I mean and how will that work

Keep up the good work

@toddparker
Contributor

@pkora - Sure, I understand. Looking forward to seeing your recommendations. Thanks.

@dcarrith
Contributor

I installed CM9 (ICS 4.0.3) on my Touchpad early this morning before the SOPA blackout on RootzWiki. I haven't had any time to do anything more than a little spot testing, but l'll be doing some testing later tonight. From the little testing I did, the transitions looked really good. The flow transition in particular was smooth as butta'.

@pcans
pcans commented Jan 20, 2012

Disabling hardware acceleration on my phonegap app made my jquerymobile transitions way smoother on Android ICS.

@toddparker
Contributor

@dcarrrith - Good to hear your ICS tests looked good. Seems to be a wide range of performance across devices/versions.

@pcans - Now that is both counterintuitive and very interesting. Mind posting how you did that so others can give it a try?

@pcans
pcans commented Jan 20, 2012

Sure, just add android:hardwareAccelerated="false" in the application entry of the AndroidManifest.xml
By default on ICS all applications are hardware accelerated. That wasn't the case previously.
I don't know how to change that for the default browser app. But if you are inside an app with an embedded webview, it might help like it did for me.

@tehraven

AndroidAndMe.com announced that ICS will default with Hardware Acceleration by default.

@toddparker
Contributor

That sounds good in theory, but why would having this ON make things worse. @pcans - can you test the transitions page in your ICS web browser, then simply embed that in a web view (w and w/o HW accel) and report back on the perf? Maybe the browser is ok and this is just a tip for app devs.

@tehraven

Well, I can say that because all apps are, by default, getting Hardware Acceleration, there could become an issue with memory. Turning it off might have cured that issue temporarily...

@pcans
pcans commented Jan 20, 2012

All the canvas demos I made on Android 2.X are now laggy in ICS. It's a bit disappointing to buy the new phone but getting bad perfs. I though it might have to do with hardware accel after reading this post by Dianne Hackborn: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

Today I tried for the first time jquery mobile and seeing all the blinking transitions I disabled harware accel.
I embedded the whole demo folder (1.0) in my PhoneGap app and tested transitions: with hardware Acceleration, transitions blink (white flash) but feel snappier. without hardware acceleration, transitions never blink, but are laggy.

Inside the standalone browser, transitions (1.0) also blink badly.

@masteinhauser

What device on ICS are you testing this? I'll test on ICS 4.0.3 on my
Prime when I have time.

On Jan 20, 2012, at 11:51, pcans
reply@reply.github.com
wrote:

All the canvas demos I made on Android 2.X are now laggy in ICS. It's a bit disappointing to buy the new phone but getting bad perfs. I though it might have to do with hardware accel after reading this post by Dianne Hackborn: https://plus.google.com/105051985738280261832/posts/2FXDCz8x93s

Today I tried for the first time jquery mobile and seeing all the blinking transitions I disabled harware accel.
I embedded the whole demo folder (1.0) in my PhoneGap app and tested transitions: with hardware Acceleration, transitions blink (white flash) but feel snappier. without hardware acceleration, transitions never blink, but are laggy.

Inside the standalone browser, transitions (1.0) also blink badly.


Reply to this email directly or view it on GitHub:
#3217 (comment)

@pcans
pcans commented Jan 20, 2012

Galaxy nexus 4.0.1

@dcarrith
Contributor

I just tested each transition (at http://jquerymobile.com/test/docs/pages/page-transitions.html) on my Touchpad running CM9 alpha0 (ICS 4.0.3) and every transition was flawless (granted, those are lightweight pages, but still). I'm not sure if the same 3D hardware acceleration that would affect these transitions is functional in this CM9 alpha0 build. I do know that there is "zero hardware-accelerated video" in this build, but I don't know if that means no hardware acceleration for anything.

@dcarrith
Contributor

Well, it may sound counter-intuitive that turning off HW acceleration would improve performance on ICS. But, after reading Dianne Hackborn's blog post (and comments) I guess it actually makes sense. Thanks for the link @pcans. I purchased the app "System Panel" so I can start monitoring memory usage more closely.

@EdwardMillen

I know it's probably a bit late now for the Android 2.x transitions, but I'm just wondering, have you looked into how the transitions are done on this page?

http://support.google.com/androidmarket/?hl=en
(needs Android user agent set in order to show mobile page)

The menus on that page somehow slide back and forth extremely smoothly on my Desire Z with Android 2.2, whereas the jQuery Mobile transitions are extremely choppy, as described.

So could it be that Google are doing their transitions a completely different way, or is it just that it's faster because the actual content to be moved back and forth is much simpler (just some text in a menu)?

@DeanMarkTaylor

I can confirm that @EdwardMillen is correct - the experience of the Android Market Support page is far smoother than the experience of the jQuery Mobile Test page.

This is even true when the User Agent string is overridden in Google Chrome and the page is viewed.

The experience in both Google Chrome and on my Nexus One (Android 2.3.4) has degraded over the course of these developments when compared to jQuery Mobile 1.0a4.1, the fades just don't look slick on the Nexus One when compared to the slides that used to be in place.

I understand that times are moving on and the Nexus One is perhaps outdated - I'm just hoping you have enough people testing on the newer devices which indicate these improvements are "real".

@dcarrith
Contributor

I'm not so sure that Android market support page is all that much better. Especially considering that there are a lot of differences. For one, the whole page is white, so the background of the HTML document might be blinking, but we wouldn't notice. For my usual testing of my app that uses JQM, I set the background of my HTML doc to #00CC00 (bright green) so it's quite noticeable. I've mentioned above that if I set the background color of the HTML doc to something similar to the background of the ui-body, then it mitigates a lot of the blinkyness..even though there is still blinkyness.

One thing I noticed about the Android market support page is that they are not trying to scroll back down to the user's previous position in the page from which they came and went back to. That eliminates at least one blink. However, they do still seem to have to scroll back to the top before transitioning. For example, I scrolled down to Music and went back and forth and did notice some blinkiness caused by the need to scroll up before transitioning. I was testing on a Thunderbolt running CM7.1.1 (Android 2.3.7) in the stock browser.

@EdwardMillen

I agree it is very different, but it is certainly a huge amount smoother on my phone for whatever reason, so it should be worth finding out why.

Regarding the scrolling, it does do that on my phone too, although on mine it seems to not scroll up to the top until after the transition (or perhaps sometimes even halfway through). But I could certainly live with that if the transitions themselves worked smoothly enough (especially as I'm trying to eliminate the need to scroll in my app anyway, as much as possible).

@dcarrith
Contributor

I do agree that it does seem smoother and is worth looking into. I also agree with @DeanMarkTaylor that the fallback fade is no where near as slick as the slide. The Android market support page is very lightweight. I'm sure that has a lot to do with how it's able to be so smooth. I also have to wonder if it behaves the same way on as many devices as JQM. If I get some time, I'll see if I can put GWT in place and see how it behaves with a MUCH heavier list.

@toddparker
Contributor

I think that my points have already been made for me. Transitions will be much smoother if pages are super short, don't worry about scrolling, have few DOM elements, little CSS3, a light background and they probably throw on some backface visibility hack to force smoother rendering (which eats memory and casuses crashes). All that is well and good when you have complete control over a page and are optimizing for a single OS but when you're building a generic framework like jQM, you can't asume any of those things.

It's not like we're doing inefficient things in our transitions. They are super clean and even when we spent a ton of time simplifying these to only animate a single property (like -webkit-transform: translateX for slide), Android would still get very glitchy. If a platform has horrible performance for web standards, we can't fix that on our end. That said, if people find something that seems to improve things, please report back.

@EdwardMillen

Hmmm... that at least gives me some hope for being able to make some (perhaps Android-specific) optimisations to my app though. I've had a bit of a look at the Google page code, and while there are some differences in the transition CSS definitions, I'm guessing they wouldn't make a huge difference to anything. So it probably is just that the content is simpler.

One other thing I noticed though, on the latest jQuery Mobile blog post, there's a bit which says: "If curious, this older iteration shows our best effort to improve transitions on Android 2.x". However, when I try that link on my phone, I only get the fade transition on everything (as it says the latest jQM versions would do). Does anyone know what the correct link for the latest best-effort Android transitions is?

@toddparker
Contributor

We uploaded a copy here with the "dumbed" down Android transitions. Here, we used the 3D support test to add a class that we used to remove any of the opacity animations and just skinny these down to animating size or position. I spent days fiddling with these to look as good as possible in Android and it just didn't seem good enough to me.
http://filamentgroup.com/tests/jqm-fade-out-in-no-3d/

My new philosophy is to target features more closely so it either works very well or we keep it simple. Toolbars have the same crisp divide.

@aauren
aauren commented Jan 30, 2012

After catching up on the entire thread over the past hour I can see you guys are putting a ton of work towards this. Thanks so much for your hard work! Going through the different branches I can definitely see some improvement over the initial stages.

I did want to chime in though. I see a few people saying that the transitions look awesome for them in ICS, however, that doesn't seem to be my experience at all. I have a Galaxy Nexus on ICS 4.0.2 and I've been testing on my phone using the master (http://jquerymobile.com/test/docs/pages/page-transitions.html) and I'm have a terrible experience of it.

The fade transition is the only one that comes close to looking how it looks in Chrome for me. On the flip transitions I'll see two frames of the flip at best. Most of the time I'll see the page load with the address bar for a second, and then blink once or twice and see the page rendered in its final form. That is my experience for just about all of the transitions. Still having no transition at all looks the best on my Galaxy Nexus.

As you can see I'm new to jQuery Mobile. Is there some special way that you guys are performing the tests on the ICS devices that reportedly work fine that is different than me? I just load the page and click the transitions on my device to get the experience I'm having. Am I the only Galaxy Nexus owner that is having these issues?

Anyway, I can see that the transitions look beautiful on most other devices/browsers, and I would love to use them on my device if at all possible. Let me know if there is anything I can do/change to help you guys work towards perfecting this.

@toddparker
Contributor

@aauren - This is all in master now so www.jquerymobile.com/test is the latest and greatest version for testing. Any branches will be older.

ICS is still a bit of a mystery. We don't yet have a Galaxy Nexus or other phone that shipped with ICS because it's so new. One team member has a phone that he upgraded with a bootleg ROM but that doesn't really count in my book. We've been relying on reports from the community on ICS and it's a very mixed bag. Some people say they look great but when I tested a Nexus running 4.0.3, transitions consisted of just a few blinks and there was a noticeable hang starting and in the middle of transitions. Some have said this hang can be many seconds long.

We're in a waiting game, hoping that there will be an update to ICS that improves things. From what I see, ICS is much worse than and version of Android 2.x (3.x is horrible, another story) or even an old iPhone 3GS with transitions because they completely changed their rendering model. I think it's a combination fo the code being not fully baked and that ICS is very hardware-intensive. From what I hear, anyone who upgraded a 2.x device to ICS is seeing awful performance.

Since we're using web standards, there is very little we can do to make ICS less horrible. I would encourage people to test other frameworks 9jQ Touch, Sencha, et.c) that also have transitions to see if jQM is an outlier or if ICS just can't handle transitions. My hunch is it's the latter.

We're still looking at improving things and have been looking at the hashchange as a culprit for the long lag in starting transitions.

Any and all feedabck and help is appreciated in working through this.

@EdwardMillen

I've just been doing some more testing on the Android version of our app - not entirely sure what's changed because we have iOS and Android PhoneGapped apps and a normal web-based app all running off mostly the same code and I've only just got round to Android again after doing a lot of work for the iPhone version - but our transitions actually seem pretty smooth now even on my Desire Z with 2.2.

Most of the app's pages are now pre-loaded into the DOM though, so I'm guessing that's what made most of the difference. With the one page that currently isn't (a Terms of Service page, so it is pretty long, but just with text), it usually just jumps straight to it with no visible transition. So perhaps things could be improved by making sure the page load (and everything that happens along with it) has finished before starting the transition, although I guess that could make the user experience worse in a different way.

The app also unbinds jQM's resetActivePageHeight method which normally runs on pageshow and resize, and uses it's own code to do the same job - mainly to account for the window height calculation not working correctly with a native iOS TabBar in PhoneGap ($(window).height() seems to get the correct height with TabBar or not), but the code also seems to run more efficiently to me, so perhaps that could be making a difference too.

There is still occasionally some flickering at the end of the transitions on my phone, but this seems to be caused by the page being scrolled up by one pixel during the transition (there's a 1px white line visible at the bottom), which then jumps back down in the final frame which is when it sometimes flickers to white. I think this is quite possibly due to me overriding the resetActivePageHeight method, but I've also found that if I manually set $.mobile.defaultHomeScroll to 0 before the call to changePage, it seems to transition with the page in the correct position and no flicker. So I guess there must be some reason for this being set to 1 on Android, but I haven't quite figured out what it is yet (and I don't want to just override it without knowing why it's like that in the first place).

(I've also just tried loading up the PhoneGap version, with pre-loaded pages and the overridden code, within the normal Android browser on my phone, and that actually seems even smoother than in PhoneGap. No flickering or stuttering at all. The normal web version without preloading etc is still pretty bad though)

@EdwardMillen

Sorry, forgot to mention - this is all still on the jQM 1.0 final release, with "slide" transitions (and "pop" on one page as a dialog, but that's always bad even though it's preloaded). I did look at the "latest" code about a week ago, to see if the resetActivePageHeight calculation had been changed, but it seemed to still be the same as 1.0 anyway.

@ghost
ghost commented Jan 31, 2012

Android 4.0 ICS has problems with the autocomplete tag for inputs. If autocomplete is on, the input will show way before the rest of the page, and it will mess up the page transition no matter which you pick.

I'm testing with JQM 1.0.1. and PhoneGap 1.3 on a Nexus S that updated to 4.0 (bad bad bad decision) and pop transition is by far the worst. Fade and slide are not great but o.k.

I'm thinking of making every button, input and select cause a device buzz when touched, since the delay between clicking and visual response can be so slow.

@aauren
aauren commented Feb 1, 2012

@toddparker Thanks for the reply.

I'll try the other frameworks that you mentioned and see if I get any traction there. My suspicions are the same as yours, that it is most likely just a problem with ICS. This isn't the first JavaScript inconsistency that I've found on the Android platform. Has anyone tried engaging Google about this via a bug report or something of the sort? Is that something that I could help with?

Since I have a native ICS device is there some way that I could help the team by debugging on my device? Do you guys have some sort of instructions on how to contribute in that respect? I've always found it difficult to debug JavaScript on mobile browsers with the absence of tools like the Chrome Developer Tools or Firebug.

Let me know!

@toddparker
Contributor

I think that ICS is just sort of broken with transitions in general, this isn't a framework problem it's an Android problem (3.x is equally bad). Sencha Touch noted the ICS problems they ran into on their blog and created an issue with Google that I all encourage you to vote up by starring. I just starred it myself:
http://code.google.com/p/android/issues/detail?id=24833

http://www.sencha.com/blog/sencha-touch-2-raising-the-bar

"We’ve always treated the browser in Android 3.x as fundamentally broken, and do not plan to officially support it in Touch 2. We are currently working on improving performance in Android 4.0 – the Ice Cream Sandwich release. So far, we have found no acceptable mechanism to achieve fast and flicker-free animations. We have filed a bug with a simplified test case showing poor performance on a variety of mechanisms with the Android bug list. If you’d like to help prioritize this bug, please go to the bug page for Android bug number 24833, and “star” the bug by clicking on the star icon just before the headline. Solving this bug will help, not just Sencha Touch 2, but the entire web community developing content for the Android 4 browser. Feel free to add your own test cases as well!"

@toddparker
Contributor

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."

@hendricius

I also commented. Thanks Todd!

@hendricius

"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.

@masteinhauser

This may be the reason why I do not have any flicker on my TF201,
Transformer Prime as it was upgraded/shipped with 4.0.3.
On Feb 2, 2012 6:57 PM, "Hendrik Kleinwaechter" <
reply@reply.github.com>
wrote:

"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."


Reply to this email directly or view it on GitHub:
#3217 (comment)

@masteinhauser

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:
ASUS Transformer Prime - Android 4.0.3

URLBrowser modified by:
ASUS/NVIDIA/Google
Google Chrome Beta
http://www.jquerymobile.com/test
Transitions are smooth
Scrolling is smooth
Transitions are jerky at best
Scrolling is smooth

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.

@tehraven
tehraven commented Feb 9, 2012

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.

@kpuputti
kpuputti commented Feb 9, 2012

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."

http://gent.ilcore.com/2012/02/chrome-fast-for-android.html

@rbdcti
Contributor
rbdcti commented Feb 9, 2012

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/

@scottjehl
Contributor

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...

@toddparker
Contributor

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.
We'll have to see how Android 4.x and Chrome evolve.

@toddparker toddparker closed this Feb 21, 2012
@ghost
ghost commented Mar 20, 2012

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.

@ghost
ghost commented Mar 20, 2012

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?

@scottjehl
Contributor

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:

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?


Reply to this email directly or view it on GitHub:
#3217 (comment)

@ghost
ghost commented Mar 28, 2012

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 $.mobile.changePage. In this case even the presence of a list appeared to be enough to trigger the flashing. Speaking of dialogs, after deciding to do away with any sort of transition involving a dialog, I had to manually set "transition:'none'" on all links, buttons, and changePage commands. Setting the default $.mobile.defaultDialogTransition did work on Chrome desktop, but on Android 4.0.3 the dialogs were still happily and unhappily popping and unpopping after I set that.

@Mattgithub

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() {
$.mobile.defaultPageTransition = "none";
});

Any advice apreciated.

And well done for that new version!

@toddparker
Contributor

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.

www.jquerymobile.com/test

@dcarrith
Contributor

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.

@dcarrith
Contributor

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.

@hendricius

@dcarrith:
great job, that looks pretty slick. I really like it! It makes sense too, the scrolling looks pretty slick too.

@tehraven
tehraven commented May 2, 2012

@toddparker Any chance these changes rolling through will improve the next update for Chromium source?

@toddparker
Contributor

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?

@SarahJane87

I got rid of the flicker on iOS! With static header and footer.
I have my css as below and no data-position="fixed" on the 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 {
overflow: hidden;
-webkit-backface-visibility: hidden;
}

div.ui-header {
position:fixed;
z-index:10;
top:0;
width:100%;
padding: 13px 0;
height: 15px;
}

.ui-content {
padding-top: 57px;
padding-bottom: 54px;
overflow: auto;
position: absolute;
top: 0;
right: 0;
bottom: 0;
left: 0;
}

.ui-footer {
position:fixed;
z-index:10;
bottom:0;
width:100%;
}

@tehraven
tehraven commented May 9, 2012

@toddparker

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

@ebloch
ebloch commented May 10, 2012

@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.

@steven-fernandez

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; }
@irishshagua irishshagua referenced this issue in irishshagua/freedom-travel-deals-app Dec 27, 2012
Open

Transitions #4

@zazoo24
zazoo24 commented Mar 21, 2013

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment