Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Description • 13 years ago

Current plan is approximately
 - extend layers to allow shader "effects pipelines" to be applied to their textures at render time
 - lower SVG filters to shader programs.  I don't know yet how much dynamic compilation is needed vs. just having a static set of filter shaders like we do for all the layers shaders currently (I know almost nothing about filters atm ;)).  It would be interesting to apply traditional compiler optimizations to filter pipelines, but that's almost certainly not needed initially.
 - on systems without a GPU (or with GPU rendering forced off), implement filter shaders with SIMD instructions, using a tool like bug 486800.  Not a high priority, but I set the dep anyway.

We'll want this for d3d10 initially, for competitive reasons.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 1 • 13 years ago

I hacked around with feColorMatrix this afternoon, since it's quite straightforward to implement in GLSL.  After many pains in the neck and aches in the head from GL (though not from GLSL; nice little language!), I got ... weird results on the type="matrix" example filter from [1].  At first I only got fully-transparent pixels, even though the shader seemed to be computing sane values.  It seems like there's some problem with unpremultiplied pixels in our webgl pipeline; or maybe I didn't set something up correctly.  Anyway, easy to hack around in GLSL.  After premultiplying the results, I got a rendering quite different from our current SVG impl: see attached screenshot.  Source image is at top-left, current SVG gives bottom right, and the shader gives top-right.  I picked a pixel somewhat randomly from the thick, dark-brownish outline making up the left side of hello kitty's head, color-picked the value in GIMP, and worked out what the value should be in theory composited on opaque white.  My calculator said ~<228,228,228>; current SVG gave <251,251,251>, and the shader gave <229,229,229>.  I tried getting a fourth guess from Inkscape, by applying a raw feColorMatrix to the source image.  Inkscape rendered the pixel as <229,229,229>; bottom-right in the screenshot.  (The inkscape and shader renderings are still quite different, but I haven't investigated more.)

I'm mainly concerned that, is it really possible our current feColorMatrix impl has ~10% error, or am I just doing something wrong?  nsSVGFEColorMatrixElement::Filter() looks fine, but I didn't trace backwards or forwards from there.  If there really is a 10% error here, then that doesn't mean other filters have the same issue, but if it's relatively common, I almost wonder if we'd cause web compat problems by changing the impl :S.

My <filter>feColorMatrix</filter> didn't work in local versions of chrome or opera, sadly, although the GL stuff worked in chrome.  Probably worth investigating.

[1] http://www.w3.org/TR/SVG/filters.html#feColorMatrixElement

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 2 • 13 years ago

Could it be a color-space issue? Per spec, our current implementation would convert the input image from sRGB to linearRGB, apply the matrix, then convert back from linearRGB to sRGB:
http://www.w3.org/TR/SVG/painting.html#ColorInterpolationProperties

Monitoring nsSVGFilterInstance::EnsureColorModel would help you see what's going on.

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 3 • 13 years ago

Sounds plausible.  Is that something we'd expect Inkscape to be doing?  (I honestly don't know.)

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 4 • 13 years ago

Bingo!  color-interpolation-filters="sRGB" gave me <228,228,228> on my reference pixel.  The rendering was visually somewhere in between the Inkscape and shader ones.  Whew!

	Chris Jones [:cjones] inactive; ni?/f?/r? if you need me Reporter
	Comment 5 • 12 years ago

Optimization for important content use case.