WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
57578
[Chromium] Shadows are too dark in svg/css/composite-shadow-text.svg
https://bugs.webkit.org/show_bug.cgi?id=57578
Summary
[Chromium] Shadows are too dark in svg/css/composite-shadow-text.svg
Justin Novosad
Reported
2011-03-31 14:19:11 PDT
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 shadows 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.
Attachments
Add attachment
proposed patch, testcase, etc.
Stephen Chenney
Comment 1
2013-04-11 13:34:52 PDT
https://code.google.com/p/chromium/issues/detail?id=230553
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug