Jump to content

Search the Community

Showing results for tags 'force3d'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • HTML5 / JS
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager

Categories

There are no results to display.


Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 9 results

  1. themepunch

    New Safari Bug

    Hi Folks, When GreenSock write matrix3d on CSS Transform based on force3D / Perspective / TransformOrigin the clip-path css attribute animation just break in the Latest Safari (12.1 (14607.1.40.1.4)). See our Example above in SAFARI Latest Version, or on any iOS latest version !! . Click on Working and Not Working version to see the Effect. The only Different between those functions are the "force3d:true" setting ! Hope you have a good idea for this ? Thank you, Krisztian from ThemePunch
  2. I am seeing this strange rendering issue in Safari when attempting to run an animation with my CTA button. Upon animating the solid orange background color can flicker or change to blue or stripes. The button pulls the text & colors externally before animation runs. I center the cta button text using transform:translate(-50%, -50%) and if i remove this the error goes away. Placing force3D:true helped some, but not completely. Any ideas on how to resolve this conflict?
  3. Hello! I am trying to figure out why this codepen (included), even though I have told it "force3D: true" in both the set() and to() methods, is not using "matrix3d" for the transform. I can't seem to figure out what the difference is between my codepen and the GreenSock codepen here: https://codepen.io/GreenSock/pen/kingu. Can anyone point me to the difference? Maybe I just keep missing something simple... Thanks, Frank
  4. Hi everybody, I used to work with Greensock API inside Flash (swf), Edge Animate, and, now, in Hype Pro since Edge has been abandonned by Adobe this year. I try to extend Hype features with a GSAP Tweenmax API. But, I cannot obtain 3D real perspective with imbricated symbols. I could get this inside Edge. Why is there a problem with Hype Pro ? I send you the Hype pro file to check it. Thanks for your help. I wrote this code : CSSPlugin.defaultTransformPerspective=700; var wall = document.getElementById("wall"); TweenMax.set(wall,{rotationY:45, transformPerspective:200, transformStyle:"preserve-3d", force3D:true}); TweenMax.to(wall,4,{rotationX:180}); TweenMax.to(".square",4,{rotationY:720}); imbrication3D.hype.zip
  5. Hi, I'm working on an animation where I animate the scale, and other properties of the body tag. The scale goes from a value of 1 to a bigger value to create an effect like in Prezi, to zoom in to an element of the page. Just as is, this makes the element shown very blurry, but I found out if I set the tween's force3D property to false, it will be sharp (good) at all times. But this also makes the whole animaton very laggy. I tried to change the force3D property while animating, so it renders only a few times during the animation, to both avoid blurriness, and lag, but I don't know how to set it in the onUpdate function. So my question is, if I set the onUpdateParams to ["{self}"], what can I do in the onUpdate function with that object? (I tried calling .set() and .updateTo() on it)
  6. We're considering a switch to force3D:"auto" as the default in GSAP 1.14.3 because: Performance: whenever an element has a 3D transform applied (like matrix3d(...) or translate3d(...)), even when only 2D components are needed, that element gets "layerized" (put onto its own compositor/GPU layer), meaning it's much cheaper processing-wise to move/rotate/scale as long as its internals don't change (like its color or contents). Think of it like taking a photo of it and shuttling those pixels to the GPU and then just shift those around. The performance difference is particularly evident on mobile devices that have weak CPUs. More fair comparisons: We've seen some people comparing CSS animations on mobile devices with GSAP, and since those browsers "layerize" elements in CSS animations of transforms, the animations can look smoother and people assume GSAP is just slower when in reality the perceived difference is almost entirely related to the fact that CSS is layerizing things. These users often don't know that you can simply set force3D:true or force3D:"auto" in GSAP to get that layerizing and instantly see better performance especially on mobile devices. Also, we've seen some comparisons with VelocityJS that weren't fair because Velocity automatically uses 3D transforms on mobile devices, so the same sort of discrepancy was introduced. Once again, most people didn't realize they could get a speed boost in GSAP by setting force3D:"auto" which would make the comparison with Velocity more fair. To be clear the change would look like this in the applied CSS: //current behavior of rotation:45: transform: matrix(0.7071, 0.7071, -0.7071, 0.7071, 0, 0); //behavior if force3D:"auto" was applied to rotation:45: transform: matrix3d(0.7071, 0.7071, 0, 0, -0.7071, 0.7071, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1); So what are the down sides?: There is a small performance hit when an element is first "layerized" because the browser has to take that raster image and feed it to the GPU. In most cases, this is negligible, but if you're starting a ton of tweens at the same time of hundreds or thousands of elements and they all have to get layerized, you'll see a lag at the beginning and then things will run smoothly. Most would prefer to pay the up-front cost to get smoother animation during the tween though. There's an upcoming "will-change" attribute that you'll be able to apply to elements in modern browsers that should provide the same benefits as the 3D transform "hack". So is the force3D:"auto" behavior something that will only be relevant/beneficial in the shorter term? Should we design our API in a way that directs people toward a more standards-compliant, recommended approach heading into the future? (Keep in mind that the will-change attribute is NOT applied in most browsers yet. I think only Chrome has it right now). We've heard reports of some browsers blurring things a bit when they have a 3D transform applied, especially if you're scaling above 1. Memory is limited on the GPU, so if you just "layerize" everything, you can run out of memory and cause things to crash or perform poorly. For example, if you're animating 2000 divs on a mobile device (doubtful), this change could cause your web page to crash whereas the old version of GSAP didn't. Legacy code would perform differently (although things should look the same). Some people would just see an instant speed boost, but some might get a slightly blurry display because of #3 above. Some people consider this technique a "hack" because we'd be defining a 3D transform even if only 2D is technically needed. In general, our philosophy at GreenSock has been to avoid making a lot of assumptions or stepping on the developer's toes - give them tools to get the effect they need (like force3D:"auto") but don't force it on them by default. In this case, however, the practical reality of how things work, what's common, and the tradeoffs of not doing it may trump the "hands-off" philosophy. If we do apply this change (which is the direction we're leaning right now), we'd provide a static property to change it so that you can easily get the old behavior back if you prefer, like: CSSPlugin.defaultForce3D = false; By the way force3D:"auto" means that it will only use a 3D transform DURING the tween and then revert to 2D at the end (unless the ending values require 3D of course). force3D:true would causing the transform to remain 3D even after the tween is finished. We'd love to hear what you think. Cast your vote, and feel free to comment. Any other concerns or recommendations?
  7. Hello Everyone, I put together a codepen example showing 3 boxes rotating in the Y axis. Green box uses rotationY Red box uses transform: rotateY() Blue box uses transform: rotate3d() Example: http://codepen.io/jonathan/pen/Kgmtn If you look at the red box, and inspect that elements code, you will see how the red box is using matrix3d() instead of the simple transform rotateY() Is there something im missing to why matrix3d() is being used? Is there a way to force GSAP to use the simple transform rotateY() transform function instead of matrix / matrix3d? Thanks again for any help?
  8. thewebdesignerpro

    Force3D

    Hello friends, The current project I'm working on performs nicely on desktop, but kinda slow (when scrolling) on an iPad. I'm using iScroll (useTransform: true), with window.requestAnimationFrame. Since the gpu of ipad is quad-core while cpu is dual-core, will using force3d improve performance in this case? Thanks in advance!
  9. Hello Everyone, Is force3d:true deprecated.. i dont see it in the CSSPlugin docs either anymore, unless I'm mistaken and it was never there to begin with: http://api.greensock.com/js/com/greensock/plugins/CSSPlugin.html I was doing some simple animation tests and noticed that i keep getting this error regarding force3d:true in the console invalid force3d tween value: true http://cdnjs.cloudflare.com/ajax/libs/gsap/1.11.0/TweenMax.min.js Line 15 i made a simple code pen so you can see the error thrown in the console: http://codepen.io/jonathan/pen/Hcvuq I have used force3d:true before but was wondering if it was recently deprecated or am i missing something here? I even saw it using version 1.10.3 I am using the force3d:true even inside the css{} object and still seeing the message above in the console Any help as always will be highly appreciated.. Thanks