88877 2012-06-12 08:46:24 -0700 SVG Lightning filter effects incorrect under zoom 2018-01-03 16:00:45 -0800 1 1 1 Unclassified WebKit SVG 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 68469 26389 1 pdr webkit-unassigned fmalita krit rhodovan.u-szeged simon.fraser zherczeg zimmermann oldest_to_newest 646976 0 pdr 2012-06-12 08:46:24 -0700 fePointLight (and other filters) are incorrect if the page is zoomed. As an example, visit the following url and zoom in: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-light-01-f.html Expected: light sources zoom consistently. Actual: light sources change in intensity and position. (Original bug: crbug.com/130945) 647010 1 krit 2012-06-12 09:36:07 -0700 I thought we already have a bug report for that? IIRC Reni or Zoltan were working on that but seem to be busy yet. Sadly the search engine 647576 2 longsonr 2012-06-12 18:41:39 -0700 http://www.w3.org/TR/SVG/filters.html#feDiffuseLightingElement Because they operate on pixels, such filters are inherently resolution-dependent. To make ‘feDiffuseLighting’ produce resolution-independent results, an explicit value should be provided for either the ‘filterRes’ attribute on the ‘filter’ element and/or attribute ‘kernelUnitLength’. The testsuite test doesn't set these attributes so zooming in is likely to result in at least an intensity change depending on how it's implemented in Webkit. 647628 3 krit 2012-06-12 20:05:54 -0700 (In reply to comment #2) > http://www.w3.org/TR/SVG/filters.html#feDiffuseLightingElement Because they operate on pixels, such filters are inherently resolution-dependent. To make ‘feDiffuseLighting’ produce resolution-independent results, an explicit value should be provided for either the ‘filterRes’ attribute on the ‘filter’ element and/or attribute ‘kernelUnitLength’. > > The testsuite test doesn't set these attributes so zooming in is likely to result in at least an intensity change depending on how it's implemented in Webkit. At the moment the light source position is transformed by using wrong transformations. That causes the issue. This is a known bug, that we have since filters render pixel perfect. FF handles this case correctly. 647629 4 krit 2012-06-12 20:08:02 -0700 (In reply to comment #3) the issue. This is a known bug, that we have since filters render pixel perfect. s/pixel-perfect/resolution-independent/ :) 647636 5 zherczeg 2012-06-12 20:33:30 -0700 I remember this bug very well, and I think we should fix it sometimes. 649351 6 fmalita 2012-06-14 11:52:22 -0700 A couple of problems I found (related to the original bug report - http://crbug.com/13094): 1) light source positioning: currently we're not transforming the light source *at all* (zoom or no zoom) 2) FELighting is applied in unmultiplied space, but the alpha channel is calculated as if in premultiplied space (spec says Sa = max(Sr, Sg, Sb), premultiplied RGBA implied). Then when the image is converted to premultiplied for compositing, the RGB values are scaled down resulting in a darker light effect. I'll open a separate bug for #2. 1385587 7 simon.fraser 2018-01-03 16:00:45 -0800 Fixed via bug 181147 and bug 181197