For use cases like mine, any other alternative requires origin-clean image data anyway, since the workarounds usually involve getImageData or WebGL or something (and SVG itself seems to hate non-origin-clean image data, based on my tests). So having this stuff only work for origin-clean image data probably doesn't make it less useful - in cases where you want to use non-origin-clean data, maybe lean on CORS or file picker forms.
On Thu, Aug 8, 2013 at 3:35 PM, Robert O'Callahan <rob...@ocallahan.org>wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
