<CAAWBYDDK3KVe9pJ4ECm+wqw9GcrW0uYFebw6nc6_LjHnHfWkVQ@mail.gmail.com>
Current votes: None.
On Wed, Jan 25, 2012 at 6:41 AM, David Geary <david.mark.geary@gmail.com> w= rote: > On Tue, Jan 24, 2012 at 5:22 PM, Chris Marrin <cmarrin@apple.com> wrote: >> Adding filter functions to canvas would require you to re-render the ite= ms >> for every filter change and you'd have to animate it all yourself. > > Sure, but you must create a superfluous canvas for each set of images tha= t > you animate, and invoke an entirely different technology to apply the > filter. You must =C2=A0make sure that those superfluous canvases have > transparent backgrounds, no borders, and have the correct Z order so they > appear over, and not under, the primary canvas for the application. And I= 'm > sure there are other gotchas to this hybrid approach that don't immediate= ly > come to mind. > > I'd much rather use the filtering underlying API and control the renderin= g > and animation myself. Yes, it's effectively creating an ad-hoc retained-mode API out of multiple <canvas> elements solely so it can apply filtering. (Using multiple backing canvases to sprite things is a reasonable performance hack, but I don't think it should be required for basic functionality.) ~TJ