famicomboy

Here's a plunkr with a better look at what I'm doing in my application: http://plnkr.co/edit/m8rWD9?p=preview This version works as expected, but once you add in a slight delay to setting your scope data http://plnkr.co/edit/bWgbTtF2adNJaRkkJm9W?p=preview It's not able to find the items that are generated with ng-repeat.

So after more testing, I realized the issue is more related to using ng-repeats inside of my directive templates, and I'm trying to target content that those repeats would build, and need some way to know when they're all done. I've seen a couple different solutions (usually around firing a function when you hit the last index). I'm still trying to figure out how to handle that in cases where I'm using multiple ng-repeat directives and need to fire when they all are ready.

Thanks for the reply, OSUblake. I looked over your examples and tried out stuff like $timeout and $apply, and in my context, it didn't change anything. I get that you made those recommendations in the context of using ngAnimate. I use ngAnimate in other parts of the site, but it's only really used with pre-baked animation parameters, I couldn't figure out how to use it for the needs of this component. Some elements might have the same intro animation, but would need different outro animations. However, I'd be willing to try that approach if I absolutely cannot get my current approach working reliably today. The first pen you posted (adding the box classes to the directive elements) doesn't work for me because I'm trying to animate elements inside the directive template, rather than the directive element itself. I figured out that if I set a $timeout of about 2 seconds before I initialize my tweens/timelines, the tweens work pretty reliably. This tells me that the DOM elements are not ready at that point in time (in the link function). The biggest problem with that approach is that an arbitrary wait time like that because it's flimsy. It doesn't guarantee that those elements are ready at that point in time. It just happened to be the right amount of time to wait on my local version on my specific computer. I've looked everywhere and cannot find a reliable method of knowing when Angular directive template elements are actually ready on the page. The compile function wasn't it, and doing a scope.$watch to wait for the data to be available isn't it either. A little more background: the site I'm developing is fairly large with lots of directives that all have their own templates and even nested ng-repeat templates inside that. Think of it like a slideshow. I have a directive for 'slideshow' and a number of nested directives inside that for 'slide'. The slides are defined in an object in the parent controller. It has all sorts of data including copy, and animation data. This is so I can use a modular approach to the slide functionality but also customize intro and outro animations per-slide, defining my parameters, target, duration etc in the json. 'tweet-note-default': { timelineID: 'tweetNoteDefault', triggerHook: 0.01, duration: 0, type: 'triggerTween', indicator: false, timelines: { intro: [ { action: 'fromTo', selector: '.note-wrapper', duration: 0.4, fromProps: { opacity: 0 }, toProps: { opacity: 1, ease: 'Sine.easeInOut', onStart: function() { console.log('note tween start'); } } } ], outro: [ ... ] }, }, I built out wrapper functionality to parse this and feed it into TimelineMax as well. This part works as far as I can tell. Maybe it would be possible to pass data like this on to an ngAnimate module and have it work that way instead?

I've been fighting a problem for 4 days now. Using ScrollMagic with GSAP to trigger animatons (rather than tying the animation to the scroll), and I cannot get it to consistently fire tweens. I can't figure out if the way scope works in Angular is messing up the scope in TweenMax, or if having two separate timelines targeting the same DOM element is overwriting badly, but I officially need some help. I know you guys aren't super Angular geniuses but I thought maybe you would know how the scope works in TweenMax better than I do. I have two different codepens set up. One without Angular that mostly works: http://codepen.io/famicomboy/pen/bpomXL And one set up in Angular that more closely resembles how my code is set up that doesn't work at all: http://codepen.io/famicomboy/pen/EKwdBq As you scroll down, you should see a red box fade in, then a blue, then red and blue fade out. If you mess with the non-angular demo enough, it will eventually mess it up. But at the very least it calls the timelines correctly. Anyway, I'm unsure what other details you'd need but if anyone wants to help me out, I'd greatly appreciate it/donate to buy beers if I can get any insight into what is failing to make this happen.

Thanks for the replies. I really appreciate it. I have the 'all' in there more as me being lazy. The transition settings are being applied to a whole bunch of elements at the same time, so it was just easier to put in 'all'. I'll see if I can narrow it down though. @Jack: what I meant was the animation itself is smooth but the wrong easing makes the rollover appear unnatural. EDIT: Just to close this up, Jaime's fix solved the problem.

I have some mouseenter effects on buttons that are using TweenMax that looked really nice. We added a sticky topbar nav (using Foundation) that I added css transitions to the "fixed" state because we wanted the nav bar to be about 20px shorter, and adding the css transitions made it so much smoother. However, I noticed that setting the transition changed my easing function on the JS calls to Tweenmax on my mouseover animation. Yes, the TweenMax calls and CSS3 transitions are set on the same elements. Any way around this nasty side effect? I really need both effects to have different easing values. So I'm trying to use Power4.easeOut but it's getting overridden to this: transition: all 200ms cubic-bezier(0.480, 0.485, 0.540, 1.000); I'm 99% certain this is correct because everything goes back to normal if I comment out the css3 transition code, but then animates terribly when it's uncommented.

Oh yes, that works. Thanks man. I never knew about that plugin. Should've looked harder.

So I need to just tween a color property of a Starling Display Object, but can't figure a way to do it with multiple objects. Right now, I have it working, but it only works on one TweenMax at a time as I need to assign it to a variable in order to get the current progress. Is there a way I could modify the TweenMax.to() function to get it to tween hex numbers correctly? onUpdate: tweenColorUpdate, onUpdateParams: [b, b.color, 0xB2B2B2] private function tweenColorUpdate(b:BlueCube, fromColor:Number, toColor:Number):void { b.color = DataModel.interpolateColor(fromColor, toColor, cubeColorTweenMax.currentProgress); } public static function interpolateColor(fromColor:uint, toColor:uint, progress:Number):uint { var q:Number = 1-progress; var fromA:uint = (fromColor >> 24) & 0xFF; var fromR:uint = (fromColor >> 16) & 0xFF; var fromG:uint = (fromColor >> 8) & 0xFF; var fromB:uint = fromColor & 0xFF; var toA:uint = (toColor >> 24) & 0xFF; var toR:uint = (toColor >> 16) & 0xFF; var toG:uint = (toColor >> 8) & 0xFF; var toB:uint = toColor & 0xFF; var resultA:uint = fromA*q + toA*progress; var resultR:uint = fromR*q + toR*progress; var resultG:uint = fromG*q + toG*progress; var resultB:uint = fromB*q + toB*progress; var resultColor:uint = resultA << 24 | resultR << 16 | resultG << 8 | resultB; return resultColor; }

I see. I thought VideoLoader.unload() would remove the netstream. So basically I have to use dispose() and then just append a new VideoLoader instance to load it again, right? There's no way to just re-use the same VideoLoader instance?

So I decided to test my claims, and sure enough, there's something about the way VideoLoader handles the netstream that doesn't null it out properly. I went through my code and decided to handle the netstream directly by calling VideoLoader.rawContent.clear() and then passing the netstream directly into my videoclip Sprite class, and handling all the Video and Netstream stuff myself. This fixed the issue for me so it's what I have to use for this project. However, you might do some good to really test out the memory issues in the VideoLoader class.

So I've done some pretty rigorous testing, and I realize that I'm still having a crash issue. I can't get Loadermax to truly release the netstream from memory after it's been played. Before, all I had to do was Video.clear() and NetStream.close() and it went away just fine, but it's not working here. Memory just compounds until I play too many videos until it crashes. GC is running, however it does run a lot less frequently than I expect. It also does not clear the netstream from memory as well so that means there is some reference not being nulled out or reset. So when I go to play the video, this is the code I use: clipLayer.addChild(model.loader.getLoader(data.id).content); clipLayer.x = -clipLayer.width / 2; clipLayer.y = -clipLayer.height / 2; model.loader.getLoader(data.id).gotoVideoTime(0); model.loader.getLoader(data.id).playVideo(); VideoLoader(model.loader.getLoader(data.id)).netStream.addEventListener(NetStatusEvent.NET_STATUS, onNetStatus, false, 0, true); I do model.loader.getLoader().content to avoid making unnecessary references to the ContentDisplay. Then, when the clip is finished playing: (unrelated code removed) private function onNetStatus(e:NetStatusEvent):void { switch (e.info.code) { case "NetStream.Play.Stop": trace('VideoClip.NetStream.Play.Stop'); clipCleanup(); break; } } private function clipCleanup():void { VideoLoader(model.loader.getLoader(currentVideoData.id)).netStream.removeEventListener(NetStatusEvent.NET_STATUS, onNetStatus); VideoLoader(model.loader.getLoader(currentVideoData.id)).rawContent.clear(); //clear the Video object as this was what I did before VideoLoader(model.loader.getLoader(currentVideoData.id)).netStream.close(); //close the netstream model.reloadNetStream(currentVideoData); removeAllChildren(clipLayer); clipLayer = new Sprite(); addChild(clipLayer); } And then this is in my data model, where the loader instance is stored: public function reloadNetStream(d:VideoData):void { //VideoData is a custom object that is used to contain basic video properties like url, id, and netstream. //Netstream isn't being defined anymore in VideoData to remove unnecessary references if (loader.getLoader(d.id)) { VideoLoader(loader.getLoader(d.id)).unload(); VideoLoader(loader.getLoader(d.id)).load(true); } else { trace("Video ID: '" + d.id + "' doesn't exist!"); } } Since I'm not really understanding how unload() and load(true); works, I can't be sure that it's truly removing all references to the netstream. Any thoughts?

Thanks for the updated class. It works a lot better. Didn't have much time to thoroughly test it, but it got rid of the immediate issue of crashing the player so that helps me out a bunch.

I've got an application that currently loads 30 or so small .flv files at the beginning of the application. They all average 215k each. The video files are interactivity transitions, rather than a video in a player with controls. This is why I want to load them all at runtime, in order to preserve the user experience and not break continuity by having to wait for videos to start buffering when you click on a button that would activate a video. I previously used Bulkloader to manage my loading in the application, but decided to move the project over to loadermax. Using Bulkloader, I would load all the videos, which probably took a total of 25mb of memory in the player. That part was fine. However, I noticed that when I actually pulled the netstream out of the bulkloader instance and attached it to the Video instance, that is when it would decode it, which in turn would extract all that video data into the memory, and probably added 4mb to the total memory used, and would compound on every single playthrough of any single video until I called Netstream.close(). So what I had to do was play the video once, and close the netstream when it was done playing, and when it needed the video again, I would have to tell bulkloader to load it again. This wasn't a huge deal but obviously not ideal. So this all relates to LoaderMax in that loadermax seems to automatically do Video.attachNetStream() automatically in the onComplete handler, or sometime soon after. So what's happening is that I compile my application, it loads all the initial xml, css, etc. ok, but then it starts the video load and the memory used skyrockets until it hits around 1.5 gb and crashes the player. tl:dr : Is there a way to disallow the netstream to be attached to a video object to avoid these memory issues? If not, is there any other fix or issue regarding the NetStream class that I'm not understanding correctly that would help me achieve the user experience?