jedrichards

Yup, see my previous post (about 4 up from this one).

Yup, just with that minimal HTML, and only tweenlite.js (no css or easing classes) I'm still seeing a RAF call cause a composite layers event. If I turn on "show paint rectangles" I'm not seeing any actual visual repainting of page resions, but the RAF call is definitely triggering a "composite layers" event. My guess is that a RAF call will automatically cause the new GPU accelerated rendering model to composite layers in my version of Chrome. The fans spinning up on my Macbook Air generally signify something going on with the GPU (its quite under-powered). Here's someone on SO noticing that RAF causes a composite layers: http://stackoverflow.com/questions/12172512/requestanimation-vs-settimeout More about GPU acceleration in Chrome: http://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome For my part there was a noticeable system-wide slow down once tweenlite had been hammering RAF/composite layers for a few mins, plus fans kicking in, plus laptop getting quite hot. I guess this might be a temporary issue while Google fine tune the whole GPU accelerated side of things, but seems to me to point towards RAF idling being a sensible default for the time being? Who knows how expertly/inexpertly other browsers will implement GPU accelerated rendering in the short term?

So with 1.9.1 I'm still seeing the RAF into composite layers oddness, but as expected the RAF idling soon kicks in and things calm down. My fans don't spin up and things generally seem a bit more responsive. I'll continue with 1.9.1 for now, and let you know of any issues. I can try and further investigate the composite layers repaint if you like, but not sure how to dig into it?

Hey, here's a screenshot of Chrome dev tools. The only JS being loaded into the page are TweenLite, CSS plugin and the ease pack. I'm using Chrome 27.0.1430.0 dev, and a late 2011 Macbook Air, OSX 10.8.2. As you can see, each request animation frame call from TweenLite seems to trigger Chrome to composite layers. This definitely starts to tax something in my hardware because the fans spin up. I will try 1.9.1 ...

I've included TweenLite, the CSS plugin and the ease pack into my project via RequireJS. If I open up Chrome dev tools I can see that TweenLite is firing "Animation Frame Fired" events continuously, with each one causing a "Composite Layers" repaint. This is without executing a single tween. The memory footprint of the page sawtooths between about 5MB and 8MB inbetween the GC kicking in and my Macbook Air's fan starts to spin up! If I don't load in TweenLite and its add-ons these issues disappear. What's going on here? Is it anything to worry about? Thanks!

Bulleted lists (via ) in Flash HTML text is really buggy, and badly supported. There are a lot of problems with it: - Flash doesn't recognise the tag, only the tag- No real control over spacing/indentation - Can't easily control bullets colour - Bullets appear everywhere in the text unless you do some trick to close off the list (sorry, forgot it) In the past I've ended up rolling my own bulleted list component, i.e. looping through each item in the list and manually rendering a bullet graphic and a line of text for each one.

Yep, that's exactly right, what you need to do is add your items to both "collections", TM and the MovieClip. You add your items to the MovieClip (as before) in order for them to show up in Flash's display list and render on screen, and you add your items to TM in order for TM to inject/manage the transformation interactivity etc. Although TM manages and manipulates DisplayObjects it has nothing to do with actually rendering them on the display list.

Hey Rob I've done a number of projects that sound similar to what you're doing, i.e. masking off an area where you allow the user to re-arrange a bunch of arbitrary DisplayObjects using TransformManager, and then allow them to save off the arrangement as a JPG or whatever. I'm also a bit confused about where you're confusion is coming from! You can store your DisplayObjects in a standard DisplayObjectContainer in whatever way you were before, and just do a BitmapData.draw() on that DisplayObjectContainer in the normal way. Whether you're adding those items to a TransformManager instance as well doesn't really effect this setup. When you add an item to TransformManager you're not adding it to a display list, TransformManager isn't a DisplayObjectContainer ...

Hey guys I have an (admittedly fairly complex) DisplayObject that I'm scaling up from 1x to 1.035x quite slowly (over 2s-ish). The DisplayObject contains a smoothed, scaled and masked Bitmap, and its parent has a GlowFilter applied. When I just tween its raw scale prop the effect is smooth, but if I attempt to scale using the TransformAroundPointPlugin or the TransformAroundCenterPlugin I'm noticing quite a lot of pixel jumping/wriggling, especially along its bottom edge. The Bitmap is smoothed, the stage quality is set to best, and all measures are in place to ensure a smooth Bitmap scaling effect. Indeed, the scaling effect is smooth when I just tween the scale, the pixel jumping only appears when using the plugins. Just wondered if this is expected behaviour from the plugins, and if there's anything I can do to ameliorate it? Thanks! Jed

Awesome, thanks for looking into this! Thanks for the explanation too. Sorry for posting up the members only classes, I didn't think. Actually, my membership expired in November. Will renew presently Jed

Hey I've managed to track down the issue, and it seems to revolve around using yoyo:true and the onRepeat callback. I'm not sure what's causing the issue. I've knocked up a quick Flash Builder 4 project that hopefully demonstrates it. The code comments should be fairly self explanatory. [Link removed because it contained a .swc with members-only bonus classes] If Flash Builder 4 is no good I can make an FLA instead. Thanks very much. Jed

Right, so the actual updates/renders are slaved to the frame-rate, and when they do occur (i.e. when entering a new frame) their results are calculated via an interpolation of the progress based on the time elapsed since the start of the tween, independent of any throttling? If I got that right, its useful to know!

Thanks Jack, I'll see if I can cobble something simple together. Hopefully in doing so the problem will present itself. In Tinic's post on kaourantin.net he says that [as well as the frame-rate dropping to 2fps] "timers (AS2 Interval and AS3 Timers) are clocked down to 2 a second." So are you saying TweenLite is immune to this throttling and somehow maintains its timing even when throttled? Even its onUpdate and onComplete events firing accurately and so on?

Hi Jack I'm noticing some rendering problems when my Flash is left running in a hidden browser tab. The rendering problems centre around tweens seemingly sometimes not starting, and sometimes not completing. I'm using TweenLite 11.39, I'm not 100% whether the problems are in my code, or yours, but I think its due to the large internal changes to timing in Flash 10.1 when in hidden tabs. See: http://blog.kaourantin.net/?p=82 Just thought I'd check with you to see what you thought about these changes. As far as you know does TweenLite's timing engine perform robustly when left running in a hidden tab under Flash 10.1? In your experience what kind of timing code could potentially fail when running in a hidden tab? I'd imagine anything running on a timer or setInterval could potentially get out of sync with things when the movie is throttled down to 2fps ... this change to the Flash Player sounds well intentioned but I can imagine it breaking a lot of Flash! Thanks! Jed