New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Page transition re-think: Smoother, faster #3217

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

Comments

Projects
None yet
@toddparker
Contributor

toddparker commented Dec 5, 2011

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

This comment has been minimized.

Show comment
Hide comment
@woutervanwijk

woutervanwijk Dec 5, 2011

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.

woutervanwijk commented Dec 5, 2011

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

This comment has been minimized.

Show comment
Hide comment
@karol-f

karol-f Dec 5, 2011

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

karol-f commented Dec 5, 2011

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 6, 2011

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

ghost commented Dec 6, 2011

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

@hendricius

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Dec 12, 2011

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

hendricius commented Dec 12, 2011

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 13, 2011

I hate when it blinks too.

ghost commented Dec 13, 2011

I hate when it blinks too.

@justinribeiro

This comment has been minimized.

Show comment
Hide comment
@justinribeiro

justinribeiro Dec 14, 2011

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.

justinribeiro commented Dec 14, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Dec 14, 2011

Contributor

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

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 comment has been minimized.

Show comment
Hide comment
@patrickdet

patrickdet Dec 14, 2011

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

patrickdet commented Dec 14, 2011

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

@jblas

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Dec 14, 2011

Contributor

@patrickdet

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

Contributor

jblas commented Dec 14, 2011

@patrickdet

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

@hendricius

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Dec 15, 2011

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

hendricius commented Dec 15, 2011

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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 15, 2011

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.

Contributor

toddparker commented Dec 15, 2011

@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 comment has been minimized.

Show comment
Hide comment
@masteinhauser

masteinhauser Dec 15, 2011

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

masteinhauser commented Dec 15, 2011

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

This comment has been minimized.

Show comment
Hide comment
@jblas

jblas Dec 15, 2011

Contributor

@masteinhauser

Great read, thanks for sharing!

Contributor

jblas commented Dec 15, 2011

@masteinhauser

Great read, thanks for sharing!

@Brian-McIntosh

This comment has been minimized.

Show comment
Hide comment
@Brian-McIntosh

Brian-McIntosh Dec 22, 2011

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.

Brian-McIntosh commented Dec 22, 2011

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 22, 2011

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.

Contributor

toddparker commented Dec 22, 2011

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

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 23, 2011

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

ghost commented Dec 23, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tehraven

tehraven Dec 23, 2011

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

tehraven commented Dec 23, 2011

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

@gehriga

This comment has been minimized.

Show comment
Hide comment
@gehriga

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

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

This comment has been minimized.

Show comment
Hide comment
@kenjiru

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

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Dec 27, 2011

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.

ghost commented Dec 27, 2011

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

This comment has been minimized.

Show comment
Hide comment
@fastpat

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

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 29, 2011

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?

Contributor

toddparker commented Dec 29, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Dec 29, 2011

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

hendricius commented Dec 29, 2011

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

@fastpat

This comment has been minimized.

Show comment
Hide comment
@fastpat

fastpat 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)

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

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.

Contributor

toddparker commented Dec 30, 2011

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

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
Contributor

toddparker commented Dec 30, 2011

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

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 30, 2011

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

Contributor

scottjehl commented Dec 30, 2011

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

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 30, 2011

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Dec 30, 2011

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)

Contributor

scottjehl commented Dec 30, 2011

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

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

Contributor

toddparker commented Dec 30, 2011

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

This comment has been minimized.

Show comment
Hide comment
@tehraven

tehraven Dec 30, 2011

@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

tehraven commented Dec 30, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

Contributor

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

Contributor

toddparker commented Dec 30, 2011

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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

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.

Contributor

toddparker commented Dec 30, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 30, 2011

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 30, 2011

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Dec 30, 2011

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.

Contributor

toddparker commented Dec 30, 2011

@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

This comment has been minimized.

Show comment
Hide comment
@staabm

staabm Dec 30, 2011

Contributor

Thanks for pointing out this workarround ;-)

Contributor

staabm commented Dec 30, 2011

Thanks for pointing out this workarround ;-)

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 25, 2012

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.

Contributor

toddparker commented Jan 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@EdwardMillen

EdwardMillen Jan 25, 2012

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?

EdwardMillen commented Jan 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 25, 2012

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.

Contributor

toddparker commented Jan 25, 2012

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

This comment has been minimized.

Show comment
Hide comment
@aauren

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

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Jan 30, 2012

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.

Contributor

toddparker commented Jan 30, 2012

@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

This comment has been minimized.

Show comment
Hide comment
@EdwardMillen

EdwardMillen Jan 31, 2012

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 commented Jan 31, 2012

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

This comment has been minimized.

Show comment
Hide comment
@EdwardMillen

EdwardMillen Jan 31, 2012

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.

EdwardMillen commented Jan 31, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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

This comment has been minimized.

Show comment
Hide comment
@aauren

aauren 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!

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 2, 2012

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

Contributor

toddparker commented Feb 2, 2012

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 2, 2012

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

Contributor

toddparker commented Feb 2, 2012

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

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Feb 2, 2012

I also commented. Thanks Todd!

hendricius commented Feb 2, 2012

I also commented. Thanks Todd!

@hendricius

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Feb 3, 2012

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

hendricius commented Feb 3, 2012

"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 comment has been minimized.

Show comment
Hide comment
@masteinhauser

masteinhauser Feb 3, 2012

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 commented Feb 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@masteinhauser

masteinhauser Feb 7, 2012

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.

masteinhauser commented Feb 7, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tehraven

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

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

This comment has been minimized.

Show comment
Hide comment
@kpuputti

kpuputti 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

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

This comment has been minimized.

Show comment
Hide comment
@rbdcti

rbdcti Feb 9, 2012

Contributor

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/

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/

@BrentHathaway

This comment has been minimized.

Show comment
Hide comment

BrentHathaway commented Feb 16, 2012

@scottjehl

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Feb 21, 2012

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

Contributor

scottjehl commented Feb 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Feb 21, 2012

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.

Contributor

toddparker commented Feb 21, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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

This comment has been minimized.

Show comment
Hide comment
@scottjehl

scottjehl Mar 20, 2012

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)

Contributor

scottjehl commented Mar 20, 2012

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

This comment has been minimized.

Show comment
Hide comment
@ghost

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

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

This comment has been minimized.

Show comment
Hide comment
@Mattgithub

Mattgithub Apr 23, 2012

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!

Mattgithub commented Apr 23, 2012

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

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker Apr 23, 2012

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

Contributor

toddparker commented Apr 23, 2012

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

This comment has been minimized.

Show comment
Hide comment
@dcarrith

dcarrith Apr 23, 2012

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.

Contributor

dcarrith commented Apr 23, 2012

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

This comment has been minimized.

Show comment
Hide comment
@dcarrith

dcarrith Apr 24, 2012

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.

Contributor

dcarrith commented Apr 24, 2012

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

This comment has been minimized.

Show comment
Hide comment
@hendricius

hendricius Apr 25, 2012

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

hendricius commented Apr 25, 2012

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

@tehraven

This comment has been minimized.

Show comment
Hide comment
@tehraven

tehraven May 2, 2012

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

tehraven commented May 2, 2012

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

@toddparker

This comment has been minimized.

Show comment
Hide comment
@toddparker

toddparker May 3, 2012

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?

Contributor

toddparker commented May 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@SarahJane87

SarahJane87 May 3, 2012

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%;
}

SarahJane87 commented May 3, 2012

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

This comment has been minimized.

Show comment
Hide comment
@tehraven

tehraven 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

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

This comment has been minimized.

Show comment
Hide comment
@ebloch

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

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

This comment has been minimized.

Show comment
Hide comment
@steven-fernandez

steven-fernandez Sep 13, 2012

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; }

steven-fernandez commented Sep 13, 2012

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; }
@zazoo24

This comment has been minimized.

Show comment
Hide comment
@zazoo24

zazoo24 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

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