WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
235604
DrawGlyphsRecorder::recordDrawGlyphs() triggers the creation of out of line Colors
https://bugs.webkit.org/show_bug.cgi?id=235604
Summary
DrawGlyphsRecorder::recordDrawGlyphs() triggers the creation of out of line C...
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
Details
Formatted Diff
Diff
Patch
(7.42 KB, patch)
2022-05-04 14:50 PDT
,
Cameron McCormack (:heycam)
no flags
Details
Formatted Diff
Diff
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.
Top of Page
Format For Printing
XML
Clone This Bug