Opened 8 years ago

Closed 7 years ago

#13812 closed enhancement (worksforme)

[enhancement] Moving from CSS Animation (key-frame) to CSS Transition

Reported by: zhangyp Owned by: ykami
Priority: high Milestone: 1.8
Component: DojoX Mobile Version: 1.7.0b1
Keywords: Cc: Chris Mitchell, Eric Durocher
Blocked By: Blocking:

Description

For better and smooth page transition, jQuery Mobile has started moving from key-frame solution to CSS transition. That is just exactly what I am prototyping in dojox.app with new transition utility based on CSS Transition. Currently it works on webkit browsers, Firefox and Firefox Mobile. We need to enable that in dojo mobile to address the competition.

Attachments (7)

View.svn.2.patch (1.8 KB) - added by zhangyp 8 years ago.
View.svn.patch (1.8 KB) - added by zhangyp 8 years ago.
transit.js (2.2 KB) - added by zhangyp 8 years ago.
transition.js (11.4 KB) - added by zhangyp 8 years ago.
css3transition.svn.patch (5.6 KB) - added by zhangyp 8 years ago.
tests.zip (3.8 KB) - added by zhangyp 8 years ago.
updated tests which will use the new transition
view2.svn.patch (640 bytes) - added by zhangyp 8 years ago.

Download all attachments as: .zip

Change History (53)

comment:1 Changed 8 years ago by ykami

We already spent some time to try the CSS transition approach with various devices when you suggested it before, but the result was the same or even worse in some cases especially for android flicker issues. Furthermore, some of the transitions can be written using the CSS transition, but some others can't. We can't move everything to the CSS transition. Use of the two different approaches could bring additional complexity. We will be looking at how your prototype goes.

comment:2 Changed 8 years ago by zhangyp

I did not see any flicker issue of CSS transition on Android, even with the low-end phone like HTC wildfire, although the UI responds quite slow on HTC Wildfire.CSS transition is designed to handle the state and frames in the transition better which will prevent flicker from happening.

Do you have any information about how you're using CSS transition? I think there might be something wrong there.

As to migrating all transition effects to CSS transition, I do not expect it will be easy and worthwhile. Currently, in my view, developers does not use those advanced transition effects when developing mobile web applications. We need to focus on the basic transitions and improve their quality across different platforms rather than provide the cool effects which has some difficulties in running across platforms. Therefore, the current CSS3 Transition prototype in dojox.app only covers basic transitions.

comment:3 Changed 8 years ago by ykami

I'm not sure how you tested the CSS translation, but the android flicker issues we had been facing were problems that happened mainly with ScrollableView. If you manage to get it to work better than the existing ones, please let me know. As you may know, all the exisisting transition animations are in the dojox/mobile/themes/common/transitions folder. They are all simple and small css files. You should easily be able to add your own transitions. If you want to add a new transition animation "foo", you should define styles for "mblFoo".

BTW, could you give me pointers to info that describes transition works better than animation on android? I'm interested in and looking for such info.

comment:4 Changed 8 years ago by zhangyp

I guess I know why the CSS transition does not work. When I use the CSS transition, I use javascript to control the states of the transition and does not use CSS classes to do that. I guess the problems might be there. Also, I tried modified the _doTransition() in view.js to make CSS transition run with test_transition-animations.html and test_transition-animations2.html. It works with both view and scrollable view.

As for the info, you can look at Todd Parker's blog about why jQuery Mobile is moving to CSS transition. http://jquerymobile.com/blog/2011/08/26/team-update-week-of-august-22nd/

comment:5 Changed 8 years ago by Tom Elliott

zhangyp, I just (quickly) read that document and it seems that it's saying transitions are not any smoother

"We were also hoping that transitions would behave more smoothly on certain platforms, as the keyframe-based animations tend to drop frames on several of the Android devices we’ve tested. In testing, however, this switch isn’t the panacea we’d hoped. In extensive testing in our lab, we’ve found that there is little difference in the smoothness of animations between keyframe and transitions on the browsers that already supported animations — iOS, Android and BB6/PlayBook."

???

comment:6 Changed 8 years ago by ykami

I guess I know why the CSS transition does not work.

I'm not saying the CSS transition does not work. When we tried, it basically worked well, but we didn't see perceivable differences, and sometimes we felt more flickers in some situations. (Perhaps this might be because the current implementation is optimized for the current animations, or there might be some conflict with ScrollableView's CSS animation.)

It works with both view and scrollable view.

So, did you see any difference? Was it more smoother than the current one?

BTW, thank you for the info. That was interesting. I am waiting for the iOS5's new scrolling capability to be available, too. I think, if we use the CSS transition for view transition, we need to change the ScrollableView's scrolling and scrollbar animations to the CSS transition as well, because in our experience, mixed use of animation and transition could end up with more instability. I will of course consider that if it's worth doing.

comment:7 in reply to:  5 Changed 8 years ago by zhangyp

Replying to mrtom:

zhangyp, I just (quickly) read that document and it seems that it's saying transitions are not any smoother

"We were also hoping that transitions would behave more smoothly on certain platforms, as the keyframe-based animations tend to drop frames on several of the Android devices we’ve tested. In testing, however, this switch isn’t the panacea we’d hoped. In extensive testing in our lab, we’ve found that there is little difference in the smoothness of animations between keyframe and transitions on the browsers that already supported animations — iOS, Android and BB6/PlayBook."

???

My understanding to this description is that jQuery Mobile found there is some problems in droping frames when using CSS3 Animation. It is a kind of problem that they could not fix during their current implementation. Therefore, they tend to use CSS3 Transition to make it smooth but see there is some difference between CSS3 Transition and key-frame. (Maybe they have not find the correct way.) I think Sencha is a better proof for CSS Transition. They used CSS Transition for the very early stage and provide the transition in Sencha Touch with least problems across iOS, Android and BB. jQuery has seen that and has started to move to Sencha's way of doing transition.

comment:8 in reply to:  6 Changed 8 years ago by zhangyp

Replying to ykami:

I guess I know why the CSS transition does not work.

I'm not saying the CSS transition does not work. When we tried, it basically worked well, but we didn't see perceivable differences, and sometimes we felt more flickers in some situations. (Perhaps this might be because the current implementation is optimized for the current animations, or there might be some conflict with ScrollableView's CSS animation.)

flicker's problem really depends on devices and their browser implementation. But if we can reduce/hide the intermediate states to prevent unnecessary UI redraw, we can solve a lot of the flicker's problem.

It works with both view and scrollable view.

So, did you see any difference? Was it more smoother than the current one?

A big difference on HTC WildFire? (I am using test with scrollable view). In original view transition (slide), it has a flicker but based on CSS 3 Transition, there is no flicker. (The reason is that although we set in css class to persist the last frame but it still pops up a UI redraw. If on fast android devices, this UI redraw might have some chance to be neglected but it will definitely redraw UI on slow devices or when the js performance is low on devices. That is why sometimes the flicker's problem is random on Android devices.)

BTW, thank you for the info. That was interesting. I am waiting for the iOS5's new scrolling capability to be available, too. I think, if we use the CSS transition for view transition, we need to change the ScrollableView's scrolling and scrollbar animations to the CSS transition as well, because in our experience, mixed use of animation and transition could end up with more instability. I will of course consider that if it's worth doing.

I think the scroll stuff majorly dealing with CSS Transform and does not use any CSS Animation or CSS Transition. But I do notices some slow UI draw when scrolling the page. I hope the moving to CSS Transition is just a start and with that we can drive the improvement on the animation (including scrolling, I do need to mention how sencha's scrolling is fast and smooth) and transition not only on dojox.mobile but also on destop application of dojo.

comment:9 Changed 8 years ago by ykami

Cc: koba added

comment:10 Changed 8 years ago by zhangyp

I have uploaded the patch to enable CSS3 Transition in dojox.mobile and modified the tests for the transition.

The patch follows original dojox.mobile transition design to switch the position of mblIn view from relative to absolute. I do not like that because it will be problematic. Position should be handled by container instead of the transition method.

I have also uploaded modified test files (with mblCSS3Transition set to true) to use CSS3 Transition.

If the transition is considered to be too fast, the transition duration can be changed to slow down in dojox/app/transition.js

Changed 8 years ago by zhangyp

Attachment: View.svn.2.patch added

Changed 8 years ago by zhangyp

Attachment: View.svn.patch added

comment:11 Changed 8 years ago by zhangyp

view.svn.patch is the same as view.svn.2.patch. I cannot delete the duplicate attachment. I hope these patches can be enabled in dojo 1.7 to provide options for users to choose whether they need to use CSS3 Transition.

comment:12 Changed 8 years ago by ykami

Thank you for the patch. My colleague koba in the Cc list, who is the main contributor of the transition animations, will be taking a look.

comment:13 Changed 8 years ago by ykami

zhangyp, we tested your code to see how the slide/flip/fade animations work on actual devices, and here's the result.

  • HTC devices: Slide and flip are improved. They work more smoothly. Fade is not improved.
  • Xoom: Did not feel differences except less flickers on fade.
  • BlackBerry: Did not feel differences.
  • iOS: Did not feel differences.

So, you are right, apparently it improves the animation behavior at least on HTC devices (and perhaps some other android devices we don't have). We will identify what makes the difference and consider how we can improve the current transition animations. We cannot use your patch as it is, since it is too late for 1.7, the code size is a bit too large for mobile, we don't want to make dependencies on dojox.app, and apparently we need more work to do, for example, we saw problems when it is used with ScrollableView with fixed bars. But your findings would be a great help for us.

comment:14 Changed 8 years ago by ykami

BTW, it looks like the jQuery Mobile team has decided not to switch from keyframe to transitions this time.

http://jquerymobile.com/blog/

comment:15 Changed 8 years ago by ykami

Oops, in the above comment, I meant to say "we have more work to do"... (;

comment:16 Changed 8 years ago by zhangyp

I hope at least in dojo 1.7 we could enable it as an option but not the default option of the transition. Although jQuery Mobile canceled their moving in beta 3, we cannot wait for jQuery Mobile and become a follower.

comment:17 Changed 8 years ago by Douglas Hays

We might want to test if specifying -webkit-transition-property can speed up the transition as well since the default is all.

comment:18 Changed 8 years ago by zhangyp

Sure. Currently I am setting it to all but we can have a try on those platform with performance issue. Also, I think this module might fit into dojox.css3 better because it can work with both desktop and mobile browsers.

comment:19 Changed 8 years ago by zhangyp

I have tested the transition using the test attached in this ticket (tests page needs to be updated to disable the compat mode when it is used in non webkit browsers).

Here is my result with new CSS transition. (transition duration is 250ms for slide, 600ms for fade and 400ms for flip)

SamSung? Galaxy S (Android 2.2) Slide, Flip and Fade all works fast and smooth. (Android has issue with skew in flip)

HTC Wildfire (Android 2.2) Slide and fade works smooth. Flip has skip frames.

iPod touch 4 (iOS 4.1) Slide, Flip and Fade all works fast and smooth.

iPad 2 (iOS 4.3) Slide, Flip and Fade all works fast and smooth.

Firefox 6(desktop) Slide, Flip and Fade all works fast and smooth.

Chrome 12(desktop) Slide, Flip and Fade all works fast and smooth.

Firefox mobile 6 (on Android 2.2 Samsung Galaxy S) Slide, Flip and Fade all works and smooth but firefox has performance issue and will lose frames when there are more elements.

Here is the result of current dojox.mobile transition which can be compared with css transition results above. (transition duration is 400ms for slide, 400ms for fade and 400ms for flip)

SamSung? Galaxy S (Android 2.2) Slide sometimes flicker. Flip has no effect. Fade works and smooth. (Android has issue with skew in flip)

HTC Wildfire (Android 2.2) Slide has clear flicker every time and fade works smooth. Flip has no effect.

iPod touch 4 (iOS 4.1) Slide, Flip and Fade all works fast and smooth.

iPad 2 (iOS 4.3) Slide, Flip and Fade all works fast and smooth.

Firefox 6(desktop) Use compat mode. Depends on javascript to do the transition effects

Chrome 12(desktop) Slide, Flip and Fade all works fast and smooth.

Firefox mobile 6 (on Android 2.2 Samsung Galaxy S) Use compat mode. Depends on javascript to do the transition effects. Slide is quite bumpy.

Last edited 8 years ago by zhangyp (previous) (diff)

comment:20 Changed 8 years ago by Chris Mitchell

The other thing we discussed yesterday is that we want to do another rev of the patch with the following changes:

1) dojox/mobile/transition - This module will do has() checking to determine appropriate transition implementation for a given transition effect (or fallback to default effect if there are known issues). Delegate to either of the transition implementation modules (2, 3 below) to perform the effects. 2) dojox/mobile/transform-transition - The new impl from dojox/app/transition. Remove dojox/app/transition, and have dojox/app have a dependency on the new delegating dojox/mobile/transition module. 3) dojox/mobile/transform-keyframe - The current impl from dojox/mobile/transition

I agree that if these transition implementation modules can be generalized to apply not just to views, but any element (desktop or mobile), we should probably move all three modules to dojox/css3, and have dojox/mobile and dojox/app depend on them. Since the intention of dojox/app is for it to be used on both desktop and mobile browsers, and these transition effects are useful for both.

Stephen is going to perform a dependency analysis/comparison of both implementations to make sure we understand footprint with both approaches (although at first glance they look similar in size/dependencies).

comment:21 Changed 8 years ago by Chris Mitchell

As a side note, in going through the Wink toolkit to Dojo toolkit api mapping, there are other css3 functions that are in wink that probably make sense to move into a new module for transforms. We could then move the css3 common modules to core in 1.8...

applyTransition wink.fx.applyTransition = function(node, property, duration, delay, func) apply a transition to the given node applyTransformTransition wink.applyTransformTransition = function(node, duration, delay, func) apply a transform transition to the given node onTransitionEnd wink.fx.onTransitionEnd = function(node, func, persistent) connect a function to the end of a transition on the given node. getTransformPosition wink.fx.getTransformPosition = function(node) Returns the instantaneous position of the node, even during a transition. applyTranslate wink.fx.applyTranslate = function(node, x, y, force2d) apply the CSS Translation to the given node applyScale wink.fx.applyScale = function(node, x, y) apply the CSS Scale to the given node applyRotate wink.fx.applyRotate = function(node, angle) apply the CSS Rotation to the given node getTransform wink.fx.getTransform = function(node) return the transform affected to the given node setTransform wink.fx.setTransform = function(node, transform) apply the given transformation to the given node

comment:22 Changed 8 years ago by ykami

In [26585]:

Refs #13812 !strict A quick fix to use CSS transition instead of CSS animation for the three standard transition animations, fade, flip, and slide, following Stephen's suggestions. The other extended transitions still use CSS animation. Abandoned the current flip.css, and replaced it with flip2.css. Discussion on refactoring of dojox/mobile/transition should be continued.

comment:23 Changed 8 years ago by Douglas Hays

What about cover and coverv ? These are used by Opener.

comment:24 Changed 8 years ago by ykami

These are used by Opener.

Yes, that's the reason why I didn't change the cover(v). We'll deliver the same changes for cover(v) (and reveal(v)) after doing some tests.

comment:25 Changed 8 years ago by ykami

In [26597]:

Refs #13812 !strict Removed flip2 from transitions.css and inline comments.

Changed 8 years ago by zhangyp

Attachment: transit.js added

Changed 8 years ago by zhangyp

Attachment: transition.js added

comment:26 Changed 8 years ago by zhangyp

update css3transition.svn.patch which apply to original code. the original transition implementation is moved to transit.js and transition.js in dojox/css3. The current code update to css3 transition is too aggressive for dojo 1.7 (css3 transition needs to be well controlled and managed by javascript and container.). Still recommend to use original code and apply some patch to switch to css3 transition as a backup transition solution.

comment:27 Changed 8 years ago by zhangyp

add a comment about check-in 26585, the flip works wrong on Android. The sequence of first view flip out and second view flip in is not chained, guaranteed and managed. The slide does not work on HTC Wildfire. It is not quite good time right now to do the replacement like that.

comment:28 Changed 8 years ago by ykami

In [26601]:

Refs #13829, #13812 !strict Added z-index:-1 directly to the opener cover node, and reverted z-index:-1 for .mblOpenerUnderlay. Added device specific background colors to views in the transition animation test files. Changed cover/reveal to use transitions instead of animations to solve the flicker problems. (Thanks Doug, you were right. fortunately the flicker disappeared.) This change also improves view transition behaviors on HTC android devices and galaxy tab. (Stephen was right.)

comment:29 Changed 8 years ago by ykami

Stephen, would it be possible for you to add conditional require code to TransitionEvent.js and remove dependency on transition.js from TransitionEvent? This way transition.js can be optional and exchangeable, and the dojox.mobile base can isolate unused code and reduce its footprint, and you can have control over transition.js.

comment:30 Changed 8 years ago by ykami

The former version of flip didn't work at all on android. The new flip still doesn't work on android very well since it uses skew. It should work best on iOS.

comment:31 in reply to:  29 Changed 8 years ago by zhangyp

Replying to ykami:

Stephen, would it be possible for you to add conditional require code to TransitionEvent.js and remove dependency on transition.js from TransitionEvent? This way transition.js can be optional and exchangeable, and the dojox.mobile base can isolate unused code and reduce its footprint, and you can have control over transition.js.

We should remove the code which is unused. I need that transition.js as a wrapper and switch for the conditional require on dojox/css3/transit. Plus, I still do not think the current way of using transition is correct. We need fine control over these transitions.

comment:32 Changed 8 years ago by ykami

Stephen, I can understand what you mean. With the current approach, probably we could provide some platform-specific transition definition, but it would be hard to do more fine tuning like branches based on feature detection and so on. It's a trade-off between less footprint and device specific fine tuning. I can understand your requirement. I do not like to introduce hard-coded dependencies on external modules, but I think adding some mechanism to make them optional features is a good idea.

Changed 8 years ago by zhangyp

Attachment: css3transition.svn.patch added

Changed 8 years ago by zhangyp

Attachment: tests.zip added

updated tests which will use the new transition

comment:33 Changed 8 years ago by zhangyp

I have updated the patch for css transition. When apply the patch, transit.js and transition.js should also be placed into dojox/css3. The patch is based on revision 26423, it might have conflicts with check in 26585 on " this.connect(this.domNode, "webkitTransitionEnd", "onAnimationEnd");" since dojox/css3/transit will clean the view state by itself.

comment:34 Changed 8 years ago by ykami

In [26630]:

Refs #13812 !strict Applied a patch from Stephen. It conditionally requires dojox.css3 when the mblCSS3Transition config is set.

comment:35 Changed 8 years ago by ykami

The patch looks good, thanks. Let's see how it goes. Let me know if you have conflict problems.
Who's responsible for dojox.css3? Chris?

comment:36 Changed 8 years ago by Chris Mitchell

In [26636]:

refs #13812 moved transition and transit from dojox.mobile and dojox.app to dojox.css3 \!strict

comment:37 Changed 8 years ago by Chris Mitchell

In [26638]:

refs #13812 update mobile showcase to remove flip2 transition

Changed 8 years ago by zhangyp

Attachment: view2.svn.patch added

comment:38 Changed 8 years ago by zhangyp

view2.svn.patch is made to prevent conflicts on webkitTransitionEnd event.

comment:39 Changed 8 years ago by Chris Mitchell

In [26655]:

refs #13812 updates from stephen zhang for transitions, new tests. \!strict

comment:40 Changed 8 years ago by ykami

Milestone: tbd1.7
Resolution: fixed
Status: newclosed

comment:41 Changed 8 years ago by zhangyp

Are we closing this ticket? I think there is more work to do with this ticket in 1.8

comment:42 Changed 8 years ago by zhangyp

Resolution: fixed
Status: closedreopened

comment:43 Changed 8 years ago by ykami

Can you elaborate?

comment:44 Changed 8 years ago by zhangyp

Please check my comment in #27. CSS transition needs to be manipulated by javascript instead of depending on timer and delay in CSS. The timer in browser never ensures the exact time of start and end of any animation or transition.

comment:45 Changed 8 years ago by Douglas Hays

I think we need to have separate tickets since this work was already delivered in 1.7 and future work will have a different milestone. Also, CSS is greatly preferred over javascript most of the time.

comment:46 Changed 7 years ago by ykami

Cc: Eric Durocher added; koba removed
Resolution: worksforme
Status: reopenedclosed

I agree with Doug. Please create a new ticket if you have any specific problems. We have updated test_new_transition-animations*.html and tested them with 1.8 on various devices, and so far we have no problems.

Note: See TracTickets for help on using tickets.