Is it possible to disable the animation on switchview? Or even better to set a custom animation?
I did not find anything in the javadoc.
There is a NoTransition class, which seems to be made exactly for that purpose:
"Null object" pattern implementation for transition. This object should be used instead of null reference to convey an absence of transition.
(Though I don't see any transition, if I don't set a TransitionFactory)
Related
I created a mockup to demonstrate my problem. I fear the solution falls in what I did with the first example (box1).
Just not sure why I can't apply a css transform to a parent element and avoid applying it to the child element or at least override it.
Let me know if there is a way to get the effect of the first example using the transform property. I don't want the second image to be scaled as well. Just the parent div.
Note
I'm trying to use this property to enable GPU acceleration.
Have not played with this in any other browser but the chrome.
But it looks like overflow hidden set on parent element implies resizing inheritance on image.
So if you set overflow auto on the boxes to which animation is applied, it should fix the resizing inheritance.
http://jsfiddle.net/gnrlbzik/5Q8EC/ tests the overflow set to auto, that keeps image dimensions in tact.
To be semantic I don't think you should be able to stop it from transforming a child element being you are transforming/scaling it's container, not resizing it. A transform is not just animating the width like the example on box 1, it scales the x.
I believe this question is about trying to gain some performance boost by using features that use the GPU to process animations. This is possible, I believe, by effectively treating the elements as an image that the GPU then animates. Thus you are not able to have an element inside that dynamically keeps its size/shape during an animation. Maybe there is a way to counter the animation by transforming the element within that you would like to keep static, but this will probably not be efficient nor effective.
Note: I am not well versed in the actual technology webkit uses to render these transformations. So sorry if the finer details of the rendering are not quite accurate. I will update this if anyone comments with a better description of how transform works.
I wanted to use -transform to get the GPU performance perk. I guess I'll continue to use the width animation: http://jsfiddle.net/Vyaf3/22/ but with applying a css3 property that would enable the GPU acceleration.
So updateDisplayList is for laying out, positioning and sizing a component's children. It seems a waste to me, however, to have all that code running every time a render is called, even if no changes have been made to the relevant properties or child properties.
The way I get around this for performance's sake (working on mobile) is to set a flag inside of my overridden updateDisplayList that lets a big part of my own sizing/positioning code run only the first time.
Is this a bad idea/ big mistake? I just can't see the benefit to letting it run every time otherwise if I don't expect anything that affects sizing/positioning to change.
It seems a waste to me, however, to have all that code running every
time a render is called, even if no changes have been made to the
relevant properties or child properties.
I agree completely.
The way I get around this for performance's sake (working on mobile)
is to set a flag inside of my overridden updateDisplayList that lets a
big part of my own sizing/positioning code run only the first time.
What I've done--and is very common in the Flex Framework--is to have a property for every main item that needs to change. For example, our MX AutoCompleteComboBox has a property named "downArrowVisible" and if you set it to false it will hide the down arrow from display, while also resizing the textInput to spread across the full width of the component. If you set it to true; it will position items like the normal ComboBox.
So, whenever the property downArrowVisible is changed, we set a flag there, downArrowVisibleChanged; and use that property to determine whether updateDisplayList should change position of the elements. [It's slightly more complicated than that, but that is the gist]. The default of downArrowVisibleChanged is true so that during the initial setup run the children components will be sized and positioned correctly.
This sounds very similar to what you're doing; as I never have a flag property specific to updateDisplayList(). I make my flags specific to a certain piece of the layout, and only set those flags to 'no longer need to be changed' in updateDisplayList().
Is this a bad idea/ big mistake? I just can't see the benefit to
letting it run every time otherwise if I don't expect anything that
affects sizing/positioning to change.
I think it seems like a logical approach. You are correct, there is no need to having your layout code consistently running every time the component redraws.
If you will not be changing properties of your custom component at runtime and only want your updateDisplayList() routine to run once--and never again--then I think you can tie into the initialized property of the Flex Framework without adding your own Boolean value. IF the value is false, then the component hasn't been through it's initial creation process yet. If the value is true then it has.
I am building an iOS Safari touch-based app and find CSS transitions and transforms work great.
But I have two things I can't seem to achieve using just JavaScript and CSS.
Usually I want the element to translate with a duration of 0.2s. But in code I occasionally want to instantly translate (initial positioning). If I update the duration to 0 or remove the transition style entirely, it doesn't seem to have an effect (acts as if the 0.2s is immutable)
When zooming I want to update the transform-origin property. This also does not seem to work, and seems stuck at my original stylesheet-set value. Specifically I am trying to do this on the gesturestart and gestureend events
Hopefully there is an approach to making this work. Maybe setTimeout async processing?
Update:
I have a js fiddle example to better illustrate my problem in #1, and it turns out that setTimeout fixes it, but it's a strange solution that I'd be interested in improving:
http://jsfiddle.net/w9E7t/
It seems like I'm unable to do these steps synchronously:
set appropriate classes for an instant transition
apply transition style
reset classes to their default (with transition) state
You can accomplish this by using two CSS classes, one which sets the timing-duration to 0s and the other which sets it to 200ms and then applying the classes programmatically in JS. Take a look at this JSFiddle for an example.
One of Web development's best practices is to separate your document's parts into structure/content (HTML), presentation (CSS), and interaction/behavior (JS). In the example above, the presentation of the content (a timed translation) stays defined in CSS while JS is used only to respond to an interaction (a MouseClick event).
You should be able to change an element's transform-origin using the WebkitTransformOrigin style property in JS. Here is an example JSFiddle. I tested this on my iPhone4 and it correctly logged the new transform-origins in the console. Again, this can also be achieved by using JS only to listen for the gesture events and updating the element's class, while keeping the style rules of the class defined in your presentation logic (CSS).
Note well: In my examples, I am updating the element's .className. Since it is possible that your elements already have many classes, you may need to implement addClass/removeClass functions to properly set the correct classes, several examples of which can found on the Web.
Update:
Sorry for the delay... There are two ways you can approach this problem and the first you have already discovered.
Another way to handle switching back the class name is to use the webkitTransitionEnd property. This fires whenever a transition on the element finishes. It would look like this:
document.getElementById('puck').addEventListener('webkitTransitionEnd', function() {
puck
.removeClass('without_transition')
.addClass('with_transition')
}, false);
Unfortunately, when the transition-duration property is set to 0, this event is not fired :( I'm not sure if that is by design or a bug, but that's just how it's currently implemented (though I'm guessing it's by design since at this point the browser is not really doing a transition but rather just applying the transformation). The workaround in this approach is to set the transition-duration to 1ms (which will essentially look instant).
While the setTimeout approach looks hackish, many mobile framework groups use it throughout their code since the function will fire after the transition that occurs from switching classes (similar to transitionEnd). Take a look at Sencha Touch and you will find it numerous times.
I've forked your JSfiddle to show my example here.
I have a Flex application where some interactions cause many objects to require visual updates all at once. These updates translate into state changes for many MXML based components which have state based transitions. The transitions look great when just a handful of the components animate at the same time... but when all of them animate at once... the Flash Player just can't keep up.
Any ideas on how to create something of an animation pipeline so that everything can have a chance to keep up? Or maybe some other solution?
Did you try working with suspendBackgroundProcessing property of Effect or disableLayout property of Animate class descendants? You can define them on MXML animation definition nodes.
Personally, I try to stay away from the Adobe effects library as they're slow and not all that good. If you want animation 'groupings', consecutive animations, or even animation timelines, I would suggest you use TweenMax.
Flex Effects include "isPlaying" property to check whether Effect is currently playing or not. But is there a way to find out what is the direction of playback (whether the play was started with playReversedFromEnd)?
Looking at the code; it looks like a playReversed property is added to the EffectInstance of the effect that reflects the playReversedFromEnd property of the play method.
So, you can check that property ( playReversed ) on the effectInstances returned from the play method.