[Webkit-unassigned] [Bug 57578] New: [Chromium] Shadows are too dark in svg/css/composite-shadow-text.svg

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=57578

           Summary: [Chromium] Shadows are too dark in
                    svg/css/composite-shadow-text.svg
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Windows 7
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: junov at chromium.org
                CC: reed at google.com, junov at chromium.org


In Chromium on Windows and Linux (skia software rendering path). The text shadows are sometimes too dark.
Layout test svg/css/composite-shadow-text.svg demonstrates the problem.

I have investigated this issue, and found this so far:

The problem happens only in a very specific case: with SVG, filled text, blurred shadow, with a stroked outline, with a semi-transparent shadow color. 

What is happening is that the shadow is being drawn two times, one on top of the other.  Therefore, this problem is not visible when the shadow is opaque. In SkiaFontWin.cpp:paintSkiaText, there is a check to prevent the shadow from being draw twice when we draw both a fill and an outline (variable didFill).  The reason this logic does not succeed in the case of SVG text rendering is that in SVGInlineTextBox::paint, there are two separate calls to method paintText, one for the hasFill case, one for the hasStroke case.  I am not sure why this necessary, perhaps other GraphicsContext implementations require this.  The skia rendering path would be happy if there were only one drawing pass at the graphics context level, with the context configured to draw both the fill and the stroke.

Another manifestation of this issue:
When the stroke width is <= 1 (as is the case in svg/css/composite-shadow-text.svg), the entire shadow has double intensity.  However, when the stroke width is > 1, a shadow of the stroked outline is superposed on top of the shadow of the fill (which is also wrong, but in a different way).  This irregularity is caused by a detail in SkDraw::drawPath, where hairline strokes are handled using a modulated alpha approach.  The problem is that when hairline rendering is activated, the stroke width is set to 0, which has the effect of drawing the stroke as a fill when invoking paint.getMaskFilter()->filterPath.  I have not fully investigated the logic behind this, but I did try setting the stroke width to 1 for rendering hairline paths, which seemed like the appropriate thing to do.  Doing that made the behavior consistent between hairline and non-hairline strokes, but still not correct and creates image differences in about 500 layout tests because it turns out that hairline shado
 ws are used for rendering objects that are "in focus", and for a multitude of other common effects.

Another symptom that is visible in svg/css/composite-shadow-text.svg is that the shadow seems to be drawn on top of the text in some places.  This is because the shadow of the outline is drawn after the text fill.  This is caused by the same root problem.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.