Core Flex 4 – Filters in spark.filters vs flash.filters

By | April 13, 2010

After looking briefly at the API docs, I noticed that there are duplicates of several of the filter classes with the same name.  For example, there is a DropShadowFilter in the spark.filters package and there is another one by the same name in the flash.filters package.

After looking at the source for the DropShadowFilter in the spark.filters package, it appears that the filters in the spark.filters package are basically just wrappers that return their flash.filters packaged equivalent from the clone() method.  I’m guessing that they just wanted to create filters that fell inside the spark package structure that could be improved or extended at a later time.  You can easily replace this: <s:DropShadowFilter /> with this: <mx:DropShadowFilter /> and get the same result.

Any one have a better explanation?

3 thoughts on “Core Flex 4 – Filters in spark.filters vs flash.filters

  1. Tink

    This spark filters extend EventDispatcher and will dispatch events when properties change unlike the flash ones, therefore objects can listen for these changes.

    You can see this in BaseFilter.

    As you meantioned each spark filter also has a clone method

  2. Corey

    Sure, with the Spark filters, you can for example, animate one of the parameters of say a DropShadowFilter (distance for example), and the filter will automatically be re-applied to the filter stack of the owning display object (and you can see the new value of the filter immediately). Note the calls to notifyFilterChanged() in the Spark wrappers.

    Nice eh?

  3. Bill Post author

    Good point. It saw that it extends event dispatcher and I had not realized that the flash.filters did not also dispatch events.

    I was wondering what those calls to notifyFilterChanged were all about. Thanks for pointing that out.


Leave a Reply

Your email address will not be published. Required fields are marked *