Open Bug 1152729 Opened 9 years ago Updated 2 years ago

[SVG] feColorMatrix inverse colors incorrectly


(Core :: Graphics, defect, P3)

37 Branch





(Reporter: iamgrief, Unassigned)


(Whiteboard: [gfx-noted])


(5 files)

Attached image black-square.svg
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150403142420

Steps to reproduce:


<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg version = "1.1" baseProfile="full" xmlns = ""
     height="200" width="200">
    <filter id="i">
    <feColorMatrix in="SourceGraphic" type="matrix" values="
      -1  0  0  0  1
      0  -1  0  0  1
      0   0 -1  0  1
      0   0  0  0  1
  <rect x="0" y="0" width="200" height="100" fill="black"/>
  <rect x="0" y="100" width="200" height="100" fill="white" filter="url(#i)"/>

Actual results:

Bottom half of the square is dark grey instead of being ultimately black.

Expected results:

Black square should appear
Component: Untriaged → SVG
Product: Firefox → Core
Tested on my collegue's laptop with windows - the square has correct colour but there is a white gap between two parts exactly the same like in chrome browser under linux.
The gap is likely antialiasing. I see a simple black rect on my Mac though as I would expect as the RGB values should clamp to 0. It could be an SSE thing though I guess.
Attached image rendered.png
This is how it looks like in my browser
I've attached the rendered image of how it looks like on my monitor. If your monitor is not so good, you'll probably won't find any difference between top and bottom halves since their colours are 0-0-0 and 13-13-13 (RGB). But the actual mistake is almost 5%.

Maybe I'm doing the transformation incorrectly? I've checked twice but still.
There seem to be two issues here.  I'll address the 13-13-13 issue in a later comment, and address the "white gap" from comment 1 here to determine expected behavior and whether a new bug needs to be created.

In the original testcase the filter element has no x, y, width, or height set, so they default to -10%, -10%, 120%, 120% respectively.  The question is in what way, if any, feColorMatrix should apply to the 10% "border" whose color is not specified by the referencing rectangle.

In my testing, firefox 39 on linux and windows (not certain windows is at 39, might be 38) both seem to give that 10% "border" not painted by the rectangle a color of (0,0,0,0), i.e. transparent black.  It seems to me the spec isn't 100% clear on this, although it does specify in some other similar situations that transparent black is what should be used.  In any case, the given feColorMatrix transforms (0,0,0,0) to (255,255,255,255), and so, assuming that the 10% "border" should start as transparent black, I think the white "gap" is correct behavior.  This testcase enlarges the svg, adds a blue background, and enlarges the "border" to exaggerate the effect.

Firefox and chrome, in my testing on linux and windows, both show the white "border" after the filter is applied.  IE11 does not.  Robert, can you comment on what the expected behavior is here and whether you're still not seeing the gap on your system?

(By the way, if the white "border" is expected behavior, it can be avoided in this case by either specifying a tight x,y,width,height on the filter or by preserving alphas in the matrix by changing the last row to "0 0 0 1 0".)
Flags: needinfo?(longsonr)
Here's a screenshot of what I'm seeing on linux and windows 8.1 firefox and chrome for the testcase from comment 5.
I think the expected behaviour is what Chrome and Firefox currently does regarding the border. Anything not drawn on by the shape being rendered is transparent black.
Flags: needinfo?(longsonr)
Attached image black-square v2.svg
Here's a version of the original testcase with x="0%", y="0%", width="100%", and height="100%" set on the filter so that there's no white "border" issue.

It looks to me like there's an issue in ApplyColorMatrix_SIMD.  At the end of the function, targetData has pixels that are (1,1,1,255) when they should be (0,0,0,255) (though I must confess I'm not sure how/where the ones turn into thirteens on-screen).  (When I change the feColorMatrix to convert to black in a more straightforward way I do get the expected (0,0,0,255) at that point in the code.)  Maybe there's a rounding issue and we're getting x - x != 0?
Thanks Robert.  Confirmed that ff 37 on linux does _not_ show the white border and 39 does, so apparently that got fixed at some point.

Moving to graphics component since this seems to be a graphics issue.
Component: SVG → Graphics
Are the "13s" still an issue here?
Whiteboard: [gfx-noted]
(In reply to Milan Sreckovic [:milan] from comment #10)
> Are the "13s" still an issue here?

Yes, I still get 13s on linux 43 and nightly.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.