WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
226108
Rename ImageBuffer::transformColorSpace to transformToColorSpace, and it should take a single argument
https://bugs.webkit.org/show_bug.cgi?id=226108
Summary
Rename ImageBuffer::transformColorSpace to transformToColorSpace, and it shou...
Fujii Hironori
Reported
2021-05-21 13:34:31 PDT
(In reply to Said Abou-Hallawa from
bug #225907 comment #11
)
> Comment on
attachment 429266
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=429266&action=review
> > > Source/WebCore/platform/graphics/cairo/ImageBufferCairoBackend.cpp:103 > > + m_parameters.colorSpace = destColorSpace; > > + > > This change suggests that transformColorSpace() should take only > destColorSpace. I checked the callers of this function and I found they all > pass the same colorSpace they used to create the ImageBuffer with. So I > would suggest: > 1. Change the name of this function to transformToColorSpace > 2. Make it take only a newColorSpace.
Attachments
Patch
(10.67 KB, patch)
2021-05-23 13:46 PDT
,
Fujii Hironori
no flags
Details
Formatted Diff
Diff
Patch
(10.76 KB, patch)
2021-05-24 00:49 PDT
,
Fujii Hironori
no flags
Details
Formatted Diff
Diff
test case
(1.07 KB, image/svg+xml)
2021-05-24 20:55 PDT
,
Fujii Hironori
no flags
Details
Patch
(10.05 KB, patch)
2021-05-24 21:02 PDT
,
Fujii Hironori
no flags
Details
Formatted Diff
Diff
Patch for landing
(10.76 KB, patch)
2021-05-25 22:36 PDT
,
Fujii Hironori
no flags
Details
Formatted Diff
Diff
Patch for landing
(10.95 KB, patch)
2021-05-25 23:01 PDT
,
Fujii Hironori
no flags
Details
Formatted Diff
Diff
Show Obsolete
(4)
View All
Add attachment
proposed patch, testcase, etc.
Fujii Hironori
Comment 1
2021-05-23 13:46:40 PDT
Created
attachment 429477
[details]
Patch
Fujii Hironori
Comment 2
2021-05-24 00:49:35 PDT
Created
attachment 429511
[details]
Patch
Said Abou-Hallawa
Comment 3
2021-05-24 10:30:40 PDT
Comment on
attachment 429511
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=429511&action=review
> Source/WebCore/ChangeLog:7 > +
Can you say something about this change? For example, "The 'srcColorSpace' argument of ImageBuffer::transformColorSpace() should be removed because it is redundant and it is the same as ImageBuffer::colorSpace()."
> Source/WebCore/platform/graphics/cairo/ImageBufferCairoBackend.cpp:115 > + } else if (newColorSpace == DestinationColorSpace::SRGB()) {
I think there is no need to check if (newColorSpace == DestinationColorSpace::SRGB()) } else { .... } Since we checked above newColorSpace is either DestinationColorSpace::LinearSRGB() or destColorSpace == DestinationColorSpace::SRGB().
> Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp:-125 > -#if !USE(CG) > - maskerData->maskImage->transformColorSpace(DestinationColorSpace::SRGB(), colorSpace); > -#else > - UNUSED_PARAM(colorSpace); > -#endif
Why this block was removed? Should not the function just be renamed and the argument 'colorSpace' be removed?
Sam Weinig
Comment 4
2021-05-24 12:56:26 PDT
Comment on
attachment 429511
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=429511&action=review
>> Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp:-125 >> -#endif > > Why this block was removed? Should not the function just be renamed and the argument 'colorSpace' be removed?
Agreed, seems weird to remove this. Though I am not sure this ever really did what was intended. What is happening here is that if svgStyle.colorInterpolation() == ColorInterpolation::LinearRGB, an ImageBuffer is created with a LinearSRGB colorSpace. This works for the CG ports, with drawing happening in LinearSRGB space. For the cairo ports, the drawing happens in normal SRGB space, and then I guess the idea was to transform the whole image buffer to LinearSRGB here. It's not clear to me that those two operations are equivalent.
Fujii Hironori
Comment 5
2021-05-24 13:19:23 PDT
Comment on
attachment 429511
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=429511&action=review
>> Source/WebCore/ChangeLog:7 >> + > > Can you say something about this change? For example, "The 'srcColorSpace' argument of ImageBuffer::transformColorSpace() should be removed because it is redundant and it is the same as ImageBuffer::colorSpace()."
Agreed.
>> Source/WebCore/platform/graphics/cairo/ImageBufferCairoBackend.cpp:115 >> + } else if (newColorSpace == DestinationColorSpace::SRGB()) { > > I think there is no need to check if (newColorSpace == DestinationColorSpace::SRGB()) > > } else { > .... > } > > Since we checked above newColorSpace is either DestinationColorSpace::LinearSRGB() or destColorSpace == DestinationColorSpace::SRGB().
I think so. Will fix.
>>> Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp:-125 >>> -#endif >> >> Why this block was removed? Should not the function just be renamed and the argument 'colorSpace' be removed? > > Agreed, seems weird to remove this. Though I am not sure this ever really did what was intended. What is happening here is that if svgStyle.colorInterpolation() == ColorInterpolation::LinearRGB, an ImageBuffer is created with a LinearSRGB colorSpace. This works for the CG ports, with drawing happening in LinearSRGB space. > > For the cairo ports, the drawing happens in normal SRGB space, and then I guess the idea was to transform the whole image buffer to LinearSRGB here. > > It's not clear to me that those two operations are equivalent.
Good point. I think I should do the following for cairo case 1. SVGRenderingContext::createImageBuffer with SRGB 2. Call SVGRenderingContext::renderSubtreeToContext (this always renders in SRGB) 3. Do maskerData->maskImage->transformToColorSpace(colorSpace) I will study more and revise the patch. Thank you very much for pointing out.
Fujii Hironori
Comment 6
2021-05-24 20:55:07 PDT
Created
attachment 429624
[details]
test case
Fujii Hironori
Comment 7
2021-05-24 21:02:00 PDT
Created
attachment 429625
[details]
Patch
Fujii Hironori
Comment 8
2021-05-24 22:58:42 PDT
svg/custom/grayscale-gradient-mask-2.svg is another test case.
Said Abou-Hallawa
Comment 9
2021-05-25 22:17:08 PDT
Comment on
attachment 429625
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=429625&action=review
> Source/WebCore/rendering/svg/RenderSVGResourceMasker.cpp:82 > +#if USE(CG) > + auto renderingColorSpace = colorSpace; > +#else > + auto renderingColorSpace = DestinationColorSpace::SRGB(); > +#endif
I think combining the calculation of colorSpace and renderingColorSpace might be more clear. I would suggest something like this: auto maskColorSpace = DestinationColorSpace::SRGB(); auto drawColorSpace = DestinationColorSpace::SRGB(); #if ENABLE(DESTINATION_COLOR_SPACE_LINEAR_SRGB) if (svgStyle.colorInterpolation() == ColorInterpolation::LinearRGB) { #if USE(CG) maskColorSpace = DestinationColorSpace::LinearSRGB(); #endif drawColorSpace = DestinationColorSpace::LinearSRGB(); } #endif So this code is saying the default colorSpace for the mask and the drawing is SRGB. The exception happens if svgStyle.colorInterpolation is LinearRGB. In this case, the drawing colorSpace will be LinearSRGB. And the CG ports will have an exception also. The mask image will be created with LinearSRGB colorSpace.
Fujii Hironori
Comment 10
2021-05-25 22:36:10 PDT
Created
attachment 429729
[details]
Patch for landing
Fujii Hironori
Comment 11
2021-05-25 23:01:59 PDT
Created
attachment 429731
[details]
Patch for landing
Fujii Hironori
Comment 12
2021-05-25 23:30:12 PDT
Comment on
attachment 429731
[details]
Patch for landing Clearing flags on attachment: 429731 Committed
r278078
(
238157@main
): <
https://commits.webkit.org/238157@main
>
Fujii Hironori
Comment 13
2021-05-25 23:30:16 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 14
2021-05-25 23:31:23 PDT
<
rdar://problem/78496702
>
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