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?
by Tink
14 Apr 2010 at 03:51
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
by Corey
14 Apr 2010 at 07:17
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?
by Bill
14 Apr 2010 at 08:42
@Tink
Good point. It saw that it extends event dispatcher and I had not realized that the flash.filters did not also dispatch events.
@Corey
I was wondering what those calls to notifyFilterChanged were all about. Thanks for pointing that out.