Bug 235604

Summary: DrawGlyphsRecorder::recordDrawGlyphs() triggers the creation of out of line Colors
Product: WebKit Reporter: Simon Fraser (smfr) <simon.fraser>
Component: Layout and RenderingAssignee: Cameron McCormack (:heycam) <heycam>
Status: RESOLVED FIXED    
Severity: Normal CC: bfulgham, heycam, mmaxfield, sam, simon.fraser, webkit-bug-importer, zalan
Priority: P2 Keywords: InRadar
Version: Safari Technology Preview   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch none

Simon Fraser (smfr)
Reported 2022-01-25 13:30:12 PST
DrawGlyphsRecorder::recordDrawGlyphs() has code that converts CGColors to Colors, via Color::createAndPreserveColorSpace(). However, if the CSS color is, say #FF0000, which is inline, this CG-related code will make an out-of-line sRGB color, which will then compare as different to the inline color.
Attachments
Patch (7.38 KB, patch)
2022-05-03 23:31 PDT, Cameron McCormack (:heycam) 		no flags
DetailsFormatted DiffDiff
Patch (7.42 KB, patch)
2022-05-04 14:50 PDT, Cameron McCormack (:heycam) 		no flags
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1 2022-02-01 13:31:15 PST
<rdar://problem/88345680>
Sam Weinig
Comment 2 2022-02-01 14:40:44 PST
I think heycam did this deliberately for https://trac.webkit.org/changeset/281470/webkit (https://bugs.webkit.org/show_bug.cgi?id=229024). I believe the issue is that the colors lose state when when they go into the CGContextDelegateRef so we don't know what they originally were and so we err on the side of more bits.
Sam Weinig
Comment 3 2022-02-01 14:42:01 PST
Perhaps the thing to fix here is whatever code is doing the comparison you mention. Where is that?
Simon Fraser (smfr)
Comment 4 2022-02-01 15:01:05 PST
That's just Color's operator==
Cameron McCormack (:heycam)
Comment 5 2022-02-02 13:26:35 PST
Simon, where is the display list code doing the comparison of colors, and what does it use it for? If it's important for Color::operator== to distinguish equivalent colors specified using different syntaxes, we could add a different comparison function.
Simon Fraser (smfr)
Comment 6 2022-02-02 13:32:54 PST
I found this while investigating rdar://84602660. It affects the behavior of updateGraphicsContext(GraphicsContext& context, const TextPaintStyle& paintStyle, FillColorType fillColorType).
Simon Fraser (smfr)
Comment 7 2022-02-02 13:33:28 PST
Specifically the fill colors compare as different here: if (mode.contains(TextDrawingMode::Fill) && (fillColor != context.fillColor())) context.setFillColor(fillColor);
Sam Weinig
Comment 8 2022-02-03 18:24:20 PST
When Cameron wrote that code, we were using bounded SRGB for both color(srgb ...) and legacy rgb. Now, we use extended sRGB for color(srgb ) but still use bounded sRGB for legacy. So, we could consider smuggling / encoding whether to use 8-bit / inline based on whether the CGColorRef is using bounded sRGB or extended sRGB for the color space.
Cameron McCormack (:heycam)
Comment 9 2022-05-03 17:16:45 PDT
*** Bug 239953 has been marked as a duplicate of this bug. ***
Cameron McCormack (:heycam)
Comment 10 2022-05-03 23:31:15 PDT
Created attachment 458775 [details] Patch
Cameron McCormack (:heycam)
Comment 11 2022-05-04 14:50:27 PDT
Created attachment 458827 [details] Patch
EWS
Comment 12 2022-05-05 16:16:44 PDT
Committed r293867 (250329@main): <https://commits.webkit.org/250329@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 458827 [details].
Note You need to log in before you can comment on or make changes to this bug.