0

i'm receiving a very noticeable performance hit when using TweenLite to tween a filter while dragging.

private function mouseMoveEventHandler(evt:MouseEvent):void
    {
    evt.stopImmediatePropagation();

    startDrag();

    zoomTween = new TweenLite(this, 1.0, {dropShadowAmount: ZOOM_SHADOW, scaleX: 1.5, scaleY: 1.5, rotation: 10, onUpdate: updateDropShadow, onComplete: completeDropShadow, onCompleteParams: [ZOOM_SHADOW]});

    removeEventListener(MouseEvent.CLICK, mouseClickEventHandler);
    addEventListener(MouseEvent.MOUSE_UP, mouseUpEventHandler);
    addEventListener(MouseEvent.MOUSE_OUT, mouseUpEventHandler);
    }

private function updateDropShadow():void
    {
    filters = [new DropShadowFilter(dropShadowAmount, 90, 0x000000, 1.0, dropShadowAmount * 2, dropShadowAmount * 2, 1.0, 3)];
    }

private function completeDropShadow(dropShadowAmount:Number):void
    {
    this.dropShadowAmount = dropShadowAmount;
    }

i understand there is a Drop Shadow Plusing with TweenLite, but that only has the ability to tween the filter on and off, rather than change the distance or blur amount of an always visible drop shadow.

also, i'm not testing this on a mobile phone, i'm testing on my fast desktop in both Flash CS5 and the external debugger - both are lagging the display object, which is just a simple square shape, even after the zoomTween has completed.

any ideas?

Chunky Chunk
  • 16,553
  • 15
  • 84
  • 162

1 Answers1

1

You're instantiating a new TweenLite on every mousemove update. You can potentially have dozens of those happen all within the space of a single enter_frame interval. That's potentially a lot of TweenLite instances, all trying to move the same object at the same time for one second. Think hundreds of them for just a "short" mouse movement. Thousands for extended motions.

For mobile especially, you need to avoid mousemove events, as they absolutely flood the system. It's data overload. Perhaps instead you could track the change in delta over time in an enter_frame or timer event handler? Do that, and then assure that only one tweenlite exists at a time (kill the old one, or just let the old one finish before assigning a new one).

Also note that filters are going to be really hard on your mobile device. You may get this up and running on desktop, but I'd be surprised if it works out on mobile.

scriptocalypse
  • 4,942
  • 2
  • 29
  • 41
  • ok, i understand about calling all those TweenLite instances - don't know why i didn't see that. but are not mouse move events as taxing as enter frame events? – Chunky Chunk Mar 04 '11 at 22:13
  • 2
    No, they're far worse. You can have multiple mouse_move events happen in the space of a single frame. A dozen to one typically. Consider also that MouseEvents all bubble, so those dozens of events are all bubbling their way through the display list as well. stopping propagation can help, but mostly only if you do it on the capture phase instead of the bubble phase. As an experiment, set mouseEnabled = mouseChildren = false on the swf root and try swiping your finger around on a complex swf with NO mouse event handlers. Now enable mouse events and try it again. Now use a handler. – scriptocalypse Mar 04 '11 at 22:37
  • This is to illustrate that even if you don't listen for or do anything with mouse events, they're still taxing on the Flash Player. Adding a handler makes it all the worse. – scriptocalypse Mar 04 '11 at 22:38
  • thanks for clearing that up. it's good to know, especially since i was assuming that since i wasn't using any enter frame events that mouse move couldn't hurt. can you possibly expand on why filters are difficult on mobile devices? i've always understood that cacheing vectors as bitmaps helps performance, and adding bitmap filters to a display object will automatically cache them as bitmaps. – Chunky Chunk Mar 04 '11 at 23:23
  • The act of applying the filter is computationally expensive, as it can require multiple passes over all the pixels in the bitmap, and indeed can increase the dimensions of the display object (thereby expanding the size of the image in memory). Also, it's *bad* to cache as bitmap a movieclip with multiple frames, each with different artwork, because every frame update the art must be re-cached, adding to the overhead of the code that executes during the frame update. – scriptocalypse Mar 05 '11 at 01:40