Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

Search the Community

Showing results for tags 'poll'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • GreenSock Forums
    • GSAP
    • Banner Animation
    • Jobs & Freelance
  • Flash / ActionScript Archive
    • GSAP (Flash)
    • Loading (Flash)
    • TransformManager (Flash)

Product Groups

  • Club GreenSock
  • TransformManager
  • Supercharge

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


Personal Website


Twitter


CodePen


Company Website


Location


Interests

Found 3 results

  1. 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 total
  2. 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 mobi
  3. 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 pro
×