Search the Community

Please help us gauge if it would be worthwhile to get more involved with creating some products / services for banner developers. Perhaps that would be templates, videos, podcast new tools for fancy effects…we're not sure. Our goal is to better understand the needs out there and see if we can address the pain points, perhaps with a partner of ours who has a ton of knowledge in the banner ad space. http://goo.gl/forms/2ZZ3c3vzRt Please take a few minutes and fill it out; be as brutally honest as possible. If you want to chime in with other ideas that aren't mentioned, that's totally fine too (drop them in this thread below or in the survey itself). Thanks!

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?

The next update to Draggable introduces some useful new properties: pointerX pointerY endX endY The "pointer" properties refer to the mouse (or touch) location from the last event (like event.pageX) associated with that Draggable instance. The "end" properties refer to where the element will land. Those get populated as soon as the user releases the mouse (or touch). Draggable also has the following properties (which aren't new): x y xMax xMin yMax yMin Here's the dilemma: technically there's an inconsistency with the way the new names are structured compared to the existing properties - "x" and "y" are at the end instead of the beginning ("endX" vs. "xMax"). Matching the current naming structure seems awkward ("xPointer" and "yPointer" don't seem nearly as intuitive as "pointerX" and "pointerY"). I don't like having inconsistencies, though. Should we change the max/min names so that the "x" and "y" are at the end? The only awkward one is "maxX" because there are two x's at the end. So it'd mean changing them to "maxX", "minX", "maxY", and "minY". Or we could leave the old/existing properties the same and live with the inconsistency. The nice thing about this is it wouldn't break any existing code that users have written. However, since Draggable is so new, this isn't as big of an issue - if we're going to make a change to the API, it's much better to do it now before more people start using it. What are your thoughts? We need to make this decision quickly, as the goal is to release the Draggable update by tomorrow. Your input is greatly appreciated. (by the way, the upcoming new features are mentioned in this thread: http://forums.greensock.com/topic/8056-draggable-invert-bounds-behavior/#entry31763)