Jump to content
Search Community

agamemnus

Members

  • Posts

    22

  • Joined

  • Last visited

 Content Type 

Posts posted by agamemnus

    How do I kill a timeline correctly?

    in GSAP

    Posted

    So I have...:
    var timeline = new TimelineLite ()

    Then timeline.from a few times, and timeline.fromTo once, and timeline.to once. Each one has {onUpdate: onUpdate ..}.

    In the onUpdate, I run TweenMax.killTweensOf(timeline) if certain conditions are met. I logged it and it's run hundreds of times, but the timeline keeps going.

    What's up with that? Anything obvious I missed?

     

    (I'd rather not post my code...)

    Input wanted: should we change the force3D default?

    in GSAP

    Posted

    I'm not quite sure I follow this comment. Are you saying that force3D:"auto" will use up texture memory on the GPU during the animation, so you'd prefer to sacrifice [animation] performance in order to conserve texture memory? Do you feel like in 60%+ of use cases, it'll hinder things more than it will help? If so, can you explain why or provide some examples? 

     

    And for your 2nd comment, are you saying that you think {transform:"translate3d(0,0,0)"} and/or {z:0} should be interpreted the same as {force3D:true}? And do you think the extra kb and slight performance hit (probably negligible) are a worthwhile tradeoff for the apparent conformity with the current CSS behavior of transform: translate3d(0,0,0)? I just want to make sure I'm understanding your points correctly before responding. 

     

    Yes to all.

    So yes, texture memory on phones is small compared to PCs. Combine CSS stuff with canvas webgl stuff and it gets smaller... I can't really give you any specific examples except for my game (which I'd rather not mention here right now) which can crash on lower-end phones due to low texture memory.

     

    The other issue is that texture-composited sections look blurry compared to non-composited sections...

     

    @Jonathan: I will see if adding perspective helps negate some blurriness...

    Input wanted: should we change the force3D default?

    in GSAP

    Posted

    I do not think it should be a default -- texture memory can be a precious thing. Besides, things can look bad if they were all textures. Being able to set a default for new animations, though, is a good idea.

     

    I would, however, support trying to make these trigger that, because they do with plain CSS:

    1) "transform: 'translate3d(0, 0, 0)'" -- without killing Greensock specific sub-transforms (or vice-versa) in the process.

    2) "{x: 0, y: 0, z: 0}" -- one of these needs a small value to make the 3D texturing work...

    Transform:rotate 180 degree and 360 degree

    in GSAP

    Posted

    I have the same problem with 180 and 360. Terrible and strange rotation effects in both Firefox and Chrome.

     

    I couldn't use "rotation". I don't know why -- code below. "rotation" simply doesn't work... I'm using the "robust" version, 1.14.2. I resorted to converting final_rotation to 179.9 or 359.9.

     

     

        TweenMax.to (current_wheel, 1.5, {
     ease       : Linear.easeOut,
     rotation   : final_rotation,
     onComplete : animation_complete
    })

    transform: scale is broken when invoked twice.

    in GSAP

    Posted

    Ok, I see what is happening.

     

    I set transform to scale, not webkit-transform. However, TweenMax is setting both, and my reset statement is not resetting webkit-transform. Is there a flag I can set to prevent this hidden backwards-compatibility? I understand you want to have backwards compatibility, but to hide it is not the right way.

    Setting the frames per second for tweens?

    in GSAP

    Posted

    I did do some tests... The slowdown only happens in Chrome.

     

    I made a very simple test case of the GSAP animation and it was perfectly smooth,  but on my real case it isn't. The difference is that in the real case there are more layers of parent / ancestor elements for the target element.

     

    The element was relatively positioned. Changing it to an absolutely positioned element made the effect much smoother... I think that in Chrome, there are some superfluous miniscule repositioning calculations being done, and maybe constant reflows. Chrome tends to do more anti-aliasing than Firefox (and thus reflows more, I guess).

     

    I tried disabling requestAnimationFrame as well as replacing the tween with code from two other animation libraries, and the smoothness difference on relative versus absolute positioning were the same.

    • Like 1

    Bug in GSAP or doc.

    in GSAP

    Posted

    I see. Well that does not say what it does with the non-CSS elements, is placed way below the first example, and is wayyyyyyyyyyy too long.

    Here is what I would write.. or something like this:
     

     

    NOTE: TweenMax [or whatever it should be called...] will also tween non-CSS properties and DOM attributes. If a namespace conflict exists, TweenMax will tween the non-CSS property. To tell TweenMax to tween a CSS-specific property, enclose your CSS property list in a css property; e.g.: "css: {left: 50px}".

     

     

    Even if it's rare to do this (a question mark on that..), it's extremely frustrating when your tween doesn't seem to work for no reason!

    Setting the frames per second for tweens?

    in GSAP

    Posted

    Hi. I just started using GSAP earlier today. Very nice. I'm having a little trouble though and most of the links on google are dead (probably because you updated your site a few days ago).

     

    I have an animation that reduces the size of an element, but it looks jittery because the first few frames seem to happen without much smoothing. When it gets small, it is smooth, but not when it is large. Is there any way I can control the amount of frames per second in my tween?

×
×
  • Create New...