TimoStSauber

Thanks OSUblake, Yeah I agree completely. Collusion detection isn't that straightforward, and would be mega overkill for this application of buttonery. Looks like I'll be sticking with duplicate buttons as paths, on top of the other images + masks. I just need to animate the button paths with the image masks simultaneously, so they line up. Cheers,

Hello fellow Greensockers! My conundrum is as follows: - I'm trying to layer several images on top of one another - Each image is masked with a curved / irregular shaped SVG mask (could be PNG or SVG Path or external SVG) - Each mask needs to animate - Now heres the kicker, each image needs to be clickable / interactive within the constraints of the mask area I forked Jonathan's example (http://codepen.io/jonathan/details/OyarJK), as it was already using an animated SVG/PNG mask which ticked off the 1st 3 points above. My fork is here - http://codepen.io/timostsauber/pen/zqzmKV I am using a SVG Path for the 1st mask, and a SVG file for the second mask. Just to test both. So the 1st one is not using attr for animation whilst the second one is. Each image has a hover event listener, but as you can see the top image clickable area takes up the entire banner, outside of the masked area. I realise I can achieve this with separate, invisible buttons on top of the SVG image masks, but this would mean code duplication, and also animating the invisible buttons to move with the masks + images. I tried various combinations of pointer-events on the image / SVG layers, but to no avail. So I'm very curious to know if this is possible, as this method of masking seems to be the best and most cross browser friendly. Thanks for any help in advance!

Thanks Carl, I might have a dodgy gif then? Or some weird code combination. I can't code pen the entire code as the work is not approved, but when it's approved I'll put it up for a fun diagnosis session. In the meantime I just replaced the gif with 2 pngs and created a faux animation with TweenLite / TimeLineLite. The next best thing, arguably better

Has anyone noticed that animated gifs don't appear to like being set to force3D:true? In Chrome it's fine, but in Safari the gif appears to stop playing, and remains static on the 1st frame. I'll throw up a code pen here later, but in the interests of time I wanted to see if anyone had encountered this, or if it just my imagination?

Thanks Carl, That's great. I know what you are saying, it's impossible to judge or predict performance with so many variables. Especially without a code pen example. But It's good to know I'm not missing any major best practice techniques for this kind of thing. I'm going to stick to TimeLineLite, coz it's the bomb. I managed to find the file size. And I'm switching from top / left to x / y, and adding force3D to all my Tweens. That in theory should provide the most bang for my buck on all browsers.

Thanks Carl, That's a good tip with x/y. I've been using top/left but will change everything now to x/y. At what number of elements / tweens does force3D start having a negative effect? > 10 or more like > 100? And does it matter if it is tweening transparent pngs, rather than vector elements? Or it doesn't care. And for pure performance, in your opinion would it be better to have a TimeLineLite with 10 sequenced TweenLites inside, all using time offsets and frame label offsets. Versus 10 separate TweenLites simply using delays to stagger the animation. I had originally used TimeLineLite, but had to remove the class for file size reasons, so switched to TweenLites with delays, but now I can have TimeLineLight back I'm curious if there is some benefit with one over the other, just regarding playback. I don't need any of the advanced TimeLine features, like time scaling or reverse / pause etc. It's simply playing through 15secs of animation and looping, about 10 elements in sequence. I guess in a nutshell my question is, assuming both TimeLineLite and TweenLight use the same 'tick' engine, is there slightly more overhead with TimeLineLite for playback? Which 'should' be smoother?

I'm testing force3D:true now, seems to be helping. If I'm using TweenLite with TimelineLite, do I need to define force3D:true for every TweenLite of an element? Or just the first? i.e. var tl = new TimelineLite(); tl .to(elem, 1, {left:"52px", ease:Power3.easeOut, force3D:true},"frame1") .to(elem, 1, {left:"32px", top:"10px", scale:0.75, rotation:15, ease:Power3.easeOut},"frame2") .to(elem, 1, {left:"15px", top:"84px", scale:0.8, rotation:17, ease:Power3.easeIn},"frame2+=1") .to(elem, 1, {left:"-102px", ease:Power3.easeIn},"frame4") Unfortunately I can't put a code pen up as the images / banner is still a WIP.

Hi Team, I'm building some banners, using transparent PNGs, and mostly position based tweens, with some alpha and scaling. i.e. TweenLite.to(mc, 1.5, {left:"26px", top:"30px", scale:1, rotation:-4, delay:5, ease:Power3.easeInOut}); I am using different eases, but mostly Power3.easeOut, and noticed that on Safari desktop it runs smooth as, but on Chrome it can be a little 'jerky' for lack of a better word. I'm wondering if this is the ease type, or the fact it is a png? I'm trying some other ease types now, but can anyone tell me what are the best performing (lowest cost) ease types for cross browser playability with pngs? It also has to play on mobile. Cheers,

Thanks Guys, Glad I could help! I've passed on your request for official confirmation and they are working out the nuts and bolts of the CDN setup. I'll PM you as soon as I get word And I'll post back any new info I get here in this thread.

Hey Emmanuel, Actually not quite. I was advised by DoubleClick that we could use .gzip, but I had assumed this meant they would gzip it for me afterwards, since it's not possible to reference a gzip file through html i.e. blah.js.gz is a no go. But after much deliberation, it turned out that they couldn't (or wouldn't) gzip JS files on their end, but they were prepared to upload any GSAP lib files to their CDN. So they uploaded TweenLite, TimelineLite, CSSPlugin to their CDN, and provided links to use in the html. Obviously all JS files being served from their CDN will be compressed on the server side, so making a massive saving for them. And the bonus is that any files being served from a CDN do not count towards the file size limit. That's right folks, they do not count!!! I was even advised we could use the Greensock CDN if we wanted too. Of course this sounds too good to be true, so I'm triple checking now, but it seems like they are finally receiving enough interest from the Greensock community, who rely on GSAP and such libs to build banners. I think they also realise it's not fair to bill us for the total file size of JavaScript files, when they are going to be compressed by the server. We have full control over image compression on our end, so we should have similar control over the js as well in one way or another. There is only so much you can minify. So if you are working with DCS, then just send them a quick support ticket asking them if you can use GSAP CDN. If you are using another media agency then ask the same and cross your fingers ...

Ah cool. No worries. 20kb is still a massive saving - you'd think they would mention in their build guide that you could gzip files. I'll push them to mention this along with including your files in a CDN. I'm well happy now. I can have my TimeLine lite back yee-hah! Happy Tweening indeed!

I just heard back from DCS support, and some good news. Their servers do support gzipping, so at least we can gzip the TweenLite & CSSPlugin - which would be a saving of around 40kb!! 55kb -> 15kb is awesome, which means I can now bring back the TimeLineLite magic. May I ask what gzip app you are using to get these to 14kb in total? I'm using Keka, and when I gzip each of them at full strength, they come to a combined 20kb. This is still awesome, and a saving of over 50%, but am curious how you got it down to 14kb?

I wish i was kidding lol. https://support.google.com/richmedia/answer/2672512 This is a perfect example of their specs being out of touch with modern techniques. They obviously mean the main JS file shouldn't be minified, not the libraries, but its not specified so they could reject if they wanted too. This is in case they need to add tracking. This kind of makes sense in theory, but in reality if it halves the size of the file why wouldn't they want it minified. It's a win win for the client and the customer. But then they go and talk about libraries such as jQuery and Zepto, so they are obviously aware clients will want to use libraries for many tasks, such as animation etc. And then at the end they go and suggest using Google Web Designer or Adobe Edge. Which is nuts considering the base library that Edge produces is well over 100kb on it's own. And from my experience, the vast majority of ad placements on their network are 100kb or less. It's obviously teething issues DCS are going through with HTML5, and it's taking them time to get it right. I remember they had similar problems with their mandatory flash components when DCS was first released many years ago. The flash components were obviously poorly coded, and in turn had MASSIVE file sizes, sometimes over 60kb - 70kb, leaving a paltry amount left over for images and code. Sure, they do tracking and reporting really well, and have a pretty awesome admin area for publishing, but It's almost like they forget that clients might want to design a banner that actually looks semi decent !

Thanks Jack, I really appreciate you taking the time to write such a comprehensive reply The Gzip idea is a good one. I hadn't thought to ask DoubleClick if this was possible. I just sent them a support request asking if they will allow GZipped JS files. They don't even normally allow minified JS files, which is just crazy. If their web server is capable of serving GZIpped files, there is no reason why they shouldn't allow this, but I'll report back here once they let me know. We could really do with that additional ~20kb. I totally agree - they should have all of GSAP in their CDN, and not count it towards any file size. I'll suggest that too them afterwards, I don't want to push my luck. I still can't believe they are setting limits of 40kb and 100kb for HTML5 banners. They want us to use the latest technology but with 10 year old file sizes I'm so thankful for your CSSPlugin - I haven't had to do animation in a *.css for ages now, and hope to never have to do animation directly in CSS ever again thanks to GSAP + CSSPlugin!

Thanks Jack! It helps a bunch. Not for this particular project, as we are restricted to 100kb, but it will for future projects i'm sure. Whilst I'm here, have you made a lite version of the CSSPlugin by any chance? It's around ~33kb presently, and that's the minified version. It would be awesome if there was a version a tad smaller, perhaps with less features? And is there a TweenNano equivalent for JS? Or is TweenLite.min.js the smallest it goes (~25kb). Don't get me wrong, that it TINY!!! But when we work on banners every byte counts sometimes, I'm almost saddened to say. I just built an entire banner using TimelineLite, only to discover I was 10kb over the filesize, and had to replace all the beautiful TimeLineLite code with TweenLite & delays