[webkit-reviews] review granted: [Bug 225841] Add support for creating/accessing/setting non-sRGB ImageData via canvas : [Attachment 428751] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat May 15 17:18:26 PDT 2021


Darin Adler <darin at apple.com> has granted Sam Weinig <sam at webkit.org>'s request
for review:
Bug 225841: Add support for creating/accessing/setting non-sRGB ImageData via
canvas
https://bugs.webkit.org/show_bug.cgi?id=225841

Attachment 428751: Patch

https://bugs.webkit.org/attachment.cgi?id=428751&action=review




--- Comment #12 from Darin Adler <darin at apple.com> ---
Comment on attachment 428751
  --> https://bugs.webkit.org/attachment.cgi?id=428751
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=428751&action=review

> Source/WebCore/bindings/js/SerializedScriptValue.cpp:3148
> +	   auto buffer =
ImageBitmap::createImageBuffer(*scriptExecutionContextFromExecState(m_lexicalGl
obalObject), logicalSize, RenderingMode::Unaccelerated, resolutionScale);

This function is still named scriptExecutionContextFromExecState! No longer
seems quite such a good name given we don’t have something named ExecState any
more.

> Source/WebCore/html/ImageData.cpp:50
> +    if (settings && settings->colorSpace)
> +	   return *settings->colorSpace;
> +    return defaultColorSpace;

We don’t have valueSquaredOr, more’s the pity.

> Source/WebCore/html/ImageData.cpp:57
> +    auto colorSpace =
toPredefinedColorSpace(pixelBuffer.format().colorSpace);
> +    RELEASE_ASSERT(colorSpace);
> +    return adoptRef(*new ImageData(pixelBuffer.size(),
pixelBuffer.takeData(), *colorSpace));

The Optional::operator*() function already includes a RELEASE_ASSERT, so we
don’t need to add one. (I wonder if that will be an impediment to our moving
from WTF::Optional to std::optional.)

> Source/WebCore/html/ImageData.cpp:96
> +	   // FIXME: Does this need to be a "real" out of memory error with
setOutOfMemoryError called on it?

How much longer are we going to move this comment around from file to file
without asking around and fixing it?

> Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:2158
> +    // FIXME: Add support for initializing the ImageData when settings.alpha
is false, requiring
> +    // every 4th byte to be 0xFF.

This seems a peculiar FIXME. It’s about a problem that will exist once we add a
feature, and the comment is only needed if we don’t test the feature!

> Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:2171
> +    if (newImageData.hasException())
> +	   return newImageData.releaseException();
> +
> +    initializeEmptyImageData(newImageData.returnValue());
> +
> +    return newImageData;

Can we write this instead?

    if (!newImageData.hasException())
	initializeEmptyImageData(newImageData.returnValue());
    return newImageData;

> Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:2185
> +    auto imageData = ImageData::createUninitialized(std::abs(sw),
std::abs(sh), m_settings.colorSpace, settings);
> +    if (imageData.hasException())
> +	   return imageData.releaseException();
> +
> +    initializeEmptyImageData(imageData.returnValue());
> +
> +    return imageData;

Ditto.

> Source/WebCore/html/canvas/CanvasRenderingContext2DBase.cpp:2218
> +	   auto imageData =
ImageData::createUninitialized(imageDataRect.width(), imageDataRect.height(),
m_settings.colorSpace, settings);
> +	   if (imageData.hasException())
> +	       return imageData.releaseException();
> +
> +	   initializeEmptyImageData(imageData.returnValue());
> +	   
> +	   return imageData;

Ditto.

> Source/WebCore/html/canvas/PredefinedColorSpace.h:29
> +#include <wtf/Optional.h>

I think Forward.h is sufficient. Maybe trouble if some automatically generated
code tries to use the return value of toPredefinedColorSpace, but otherwise
should not be a problem.

> Source/WebCore/platform/graphics/ImageBufferBackend.cpp:120
> +    // FIXME: Add support for non 8-bit pixel formats.
> +    ASSERT(destinationFormat.pixelFormat == PixelFormat::RGBA8 ||
destinationFormat.pixelFormat == PixelFormat::BGRA8);

What makes it safe to assert here without returning nullopt?

> Source/WebCore/platform/graphics/ImageBufferBackend.cpp:157
> +    // FIXME: Add support for non 8-bit pixel formats.

I’d write non-8-bit. But also given how this is written it’s supporting only
two specific formats. The comment implies these are the only two 8-bit ones,
which might be accurate now, but will it be forever?

> Source/WebCore/platform/graphics/PixelBuffer.cpp:72
> +    // NOTE: Only 8-bit formats are currently supported.
> +    ASSERT(format.pixelFormat == PixelFormat::RGBA8 || format.pixelFormat ==
PixelFormat::BGRA8);

I wish there was a way that all these assertions shared a single comment, and a
single "list of 8-bit formats".

Also, I am not clear exactly what level protects us and makes this safe to
assert rather than runtime check and runtime fail (as I asked above).

> Source/WebCore/testing/Internals.cpp:6206
> +	       auto imageData =
ImageData::create(static_cast<unsigned>(image->width()),
static_cast<unsigned>(image->height()), { { PredefinedColorSpace::SRGB } });

Better to use static_cast than function-call-style cast, but are these type
casts both needed and safe?


More information about the webkit-reviews mailing list