On Fri, Aug 9, 2013 at 10:00 AM, Benoit Jacob <jacob.benoi...@gmail.com>wrote:
> I think that it would make more sense to first try to see to what extent we > manage to fix these issues, see what is left of SVG filters after these > issues are fixed, and only then consider propagating these concepts to more > Web APIs. (I know that an effort is under way on a tentative secure > implementation of filters. That's great. I'm just saying, let's just finish > and evaluate that first). > Markus' Moz2D code is designed to fix those issues, by avoiding large lookup tables, integer division and all floating point operations on data derived from source pixel values. He's already converted most filter implementations accordingly. I think the remaining ones are lighting, which are probably the hardest ... but I think he can handle it :-). We'll be more than happy to have you and others audit the code for constant-time-ness :-). If the intended use case is Shumway, so that --- I guess --- these filters > are intended to be applied mostly to plain text and same-origin > images/video and origin-clean canvases, then for this particular case, we > could have a "safe to read back pixels from" concept for DOM elements and > restrict filters to that. > It would be trivial to restrict canvas filters to only work on origin-clean canvases with origin-clean image data (when filtering drawImage), and that would probably suffice for Shumway. So that's an option. I hope it won't be needed though. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
