Jump to content
GreenSock

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

Search the Community

Showing results for tags 'size'.

  • 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 8 results

  1. hi there, I love the animations you can do with gsap but i'm afraid the module size is way over the limit we have here which tops at 15k per lib and at 35+ it's going to be a big job convincing my back-end friends to let me. use the lib. can you offer some advice as to what kind of reason other than great animations to use to convince the powers that be to allow the use of this beautiful lib. I'm working on a prototype demo using a dynamic progress bar but any advice will be greatly appreciated. thanks LC
  2. GreenSock

    Rethinking Kilobytes

    Conventional wisdom says that kilobytes have a direct impact on load times and consequently user experience. Too many developers, however, myopically focus on a simplistic (and rather dated) "aggregate total file size" mentality and completely miss the broader goal of improving user experience. This article aims to challenge the old paradigm and explain why "spending" kilobytes on a library like GSAP can be a very smart move. Kilobyte cost factors When you're assessing kilobyte cost in a modern, nuanced way consider these factors: Performance yield Some kilobytes are "cheap" in terms of the initial load but expensive for runtime execution. If our goal is better user experience, this is critical. Would you rather a page that loads 200ms faster with janky animations or one that's super-smooth at runtime but takes a fraction of a second longer to load? Of course there are reasonable limits either way (waiting an extra 30 seconds for a huge file to load would be intolerable even if it made things run buttery smooth), but in most cases we're only talking about fractions of a second difference. For example, GSAP contains "extra" code that automatically GPU-accelerates transforms, applies lag smoothing, avoids layout thrashing, caches important values for super-fast lookups, etc. - would removing those features for the sake of a few milliseconds on initial load (and zero savings once it's cached) be a step forward or backward? Caching When does a 23kb file act like a 0kb file? When it's cached! This is particularly relevant for engaging, animated sites because there are common tasks and code that can be encapsulated and shared. GSAP is a perfect example of a shared resource. An end user only loads it once and then it's completely "free" thereafter...for all pages pointing at that file...on all sites*! *Some browsers may implement domain-specific caching. CDN files loaded from a CDN (Content Delivery Network) are typically "faster" because they're geographically distributed and automatically loaded from the closest server. Plus CDNs have inherent redundancies leading to better reliability. Custom code reduction (kb savings) Loading a library like GSAP may allow you to only write 1kb of custom animation code instead of 5kb of CSS animation code, for example. Plus it has quite a few utility methods that you can tap into for added savings. This can significantly reduce the amount of custom code that must be loaded as your visitors go page-to-page. Non-kilobyte costs If you avoid a tried-and-true library like GSAP, it may feel like you're reducing your costs but don't forget: Development time You could use a minimalistic library or write your own, but how much more time will that take to implement? How much more custom code will it require? How many workarounds will be required to get similar functionality? How many headaches will you run into with cross-browser quirks and inconsistencies that GSAP already solved? GSAP's API has been crafted over a decade to facilitate easy experimentation with minimal code. And when it comes to animation, experimentation is key. Most developers are working against deadlines and it's priceless to have a robust, vetted toolset to rely on. Swagger & confidence Perhaps at the outset your project only has basic animation needs so you choose a basic animation library or write your own custom code for all the animations...but what happens when the client requests something more advanced? Uh oh. Will you port everything to GSAP then? What if you've got hundreds of animations that now need to be dynamically time-scaled or linked to scroll position with smooth scrubbing? How about advanced morphing? If you just use GSAP from the start, you have almost zero risk of running into an "oh no!" moment like that. You can code with confidence that you'll be able to animate pretty much anything with minimal code. What is that kind of developer swagger worth? Documentation, support & training What if you run into trouble? Is excellent documentation available? Is there a community eager to help? Are there training resources for new hires down the road? What's the real long-term impact of your choice? Maintenance The web is littered with abandoned open source projects. What's the track record of the one you're considering? How long has it been actively developed? Or if you're writing all your own animation code from scratch, is it truly maintainable? What's the long-term cost? Are you documenting how everything works? What happens when browsers introduce bugs or new features that impact animations? Other factors to consider Bandwidth is only increasing The impact of a 23kb library is decreasing all the time. It's less than a single image these days. On average, in fact, images account for over 864kb on every web page! And again, GSAP is a one-time load in most cases. It's often cached in which case it costs nothing. GSAP doesn't count against file size budgets on every major ad network They have virtually all recognized GSAP as an industry standard and exempted it from file size calculations. That directly benefits you if your animations are GSAP-based. Conclusion If you adopt the old mindset that's solely focused on the aggregate total file size for each page, it's easy to miscalculate the cost of using a library like GSAP (or any other shared resource). Doing so also pushes developers toward minimalistic less-capable solutions that may end up being far more expensive long-term. We'd encourage a more wholistic, nuanced approach that looks at the overall costs and benefits. Remember the end goals - outstanding user experience, minimal development costs, and long-term viability.
  3. Hello guys! I'm truly new using Draggable product and I'm having a problem that I didn't find any solution on web I want to increase size to my container when the target hits the edge of. Actually, I'm using edgeResistance and it work very well but instead, I need to start a function that verifies the size of container and increase X px to width or height (depends where it hits) There's any option to verify when the target hits the edge and where (x,y)? Thank you
  4. The time has came again to pour clean water into the glass. I have started to precisely unravel the mistery of Sizmek as size calculation method. I was unsuccessful. What is know at the moment from my experiments is they are definitely zipping and counting the backup image into the ad's size. But I still don't understand how they compress. I am using 7Zip with the default compression settings and my .zips are bigger than their calculated value. For instance: in case of an 213k .zip, they see 193k from it, which is a 20k difference. I have tried to delete the assest from the zip one at a time, to see what is causing this difference, but i haven't found any file which is adding 20k to the .zip. I don't think they have the ultimate comressor which is better than 7z or the default Windows zipper, this leads to the suspicion: they are excluding something. Could anyone can help me to assemble the right calculation formula? Update: It gets even weirder when I am inlining all the assets into the .html. My .htm file is 217k, backup.jpg is 24k which gives a 171k .zip. Their calculator is displaying ONLY 88k. ( Don't tell anyone but this way we can make huge ads in outstanding quality )
  5. I tried use TweenLite in this pen: http://codepen.io/lagden/pen/QjQbwp?editors=001 and nothing happens! I would like to use TweenLite, but I don't know which feature is missing for it works!! TweenMax is very heavy for it! This is my current code! It is using TweenMax and it's working. TweenMax.fromTo(circle, duration, { x, y, scale: 0, opacity: 1, transformOrigin: '50% 50%' }, { scale: 10, opacity: 0 });
  6. I have added dynamic text to my TransformManager, is it possible to change the size of dynamically added text ?
  7. Hi, Since the introduction of animation in JS, ad management programs are changing the standard of Flash to JS when it comes to advertisement. But they keep the same restrictions on KB. When I was given the task to make a banner in JS, Greensock immediately popped up in my head. I've looked at the download page and when customising the library I saw 7 kb when only selecting Tweenlite. As shown here: But when I look on my mac when inspecting the file: Am I doing something wrong downloading or am I missing something here? For the banner to be accepted @ the ad networks the JS should be under 10kb. Hope someone can help me out! Thank in advance! Youri
  8. Hi, I've found this code inside the initTweenVals() function of GSAP v10. Why is it needed? I'm not using timeScale anywhere, but is the tweening engine using it for something? if (vars.timeScale != undefined && target.hasOwnProperty("timeScale")) { tweens[tweens.length] = new TweenInfo(target, "timeScale", target.timeScale, vars.timeScale - target.timeScale, "timeScale", false); //[object, property, start, change, name, isPlugin] } Thanks
×