[Webkit-unassigned] [Bug 237128] New: [macOS][REGRESSION] (rr289518): Form controls are scaled twice on Retina display

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=237128

            Bug ID: 237128
           Summary: [macOS][REGRESSION] (rr289518): Form controls are
                    scaled twice on Retina display
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Layout and Rendering
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com
                CC: bfulgham at webkit.org, simon.fraser at apple.com,
                    zalan at apple.com

Created attachment 453070

  --> https://bugs.webkit.org/attachment.cgi?id=453070&action=review

test case

Open the attached test case on Retina display.

Result: The progress control is scaled twice.

When displaying a form control, we have to create a scratch ImageBuffer, then ask the AppKit to render the form control to the GraphicsContext of the ImageBuffer and finally draw the ImageBuffer to the destination GraphicsContext. On Retina display, we have to scale the scratch ImageBuffer by the device scaling factor. The bug happens when creating this scratch ImageBuffer

Before r289518, RenderThemeMac::paintProgressBar() had this call:

    auto imageBuffer = ImageBuffer::createCompatibleBuffer(inflatedRect.size(), deviceScaleFactor, DestinationColorSpace::SRGB(), paintInfo.context());

And this would be translated to this function:

RefPtr<ImageBuffer> ImageBuffer::createCompatibleBuffer(const FloatSize& size, float resolutionScale, const DestinationColorSpace& colorSpace, const GraphicsContext& context)
{
    return ImageBuffer::create(size, context.renderingMode(), resolutionScale, colorSpace, PixelFormat::BGRA8);
}

This means this version of createCompatibleBuffer() was just creating an ImageBuffer with context.renderingMode().

But after r289518, RenderThemeMac::paintProgressBar() the above call was changed to:

    auto imageBuffer = paintInfo.context().createImageBuffer(inflatedRect.size(), { deviceScaleFactor, deviceScaleFactor });

And this will be translated to these functions:

RefPtr<ImageBuffer> GraphicsContext::createImageBuffer(const FloatSize& size, const DestinationColorSpace& colorSpace, RenderingMode renderingMode, RenderingMethod renderingMethod) const
{
    if (renderingMethod == RenderingMethod::DisplayList)
        return ImageBuffer::create(size, renderingMode, ShouldUseDisplayList::Yes, RenderingPurpose::Unspecified, 1, colorSpace, PixelFormat::BGRA8);

     return ImageBuffer::create(size, renderingMode, 1, colorSpace, PixelFormat::BGRA8);
}

RefPtr<ImageBuffer> GraphicsContext::createImageBuffer(const FloatSize& size, const FloatSize& scale, const DestinationColorSpace& colorSpace, std::optional<RenderingMode> renderingMode, RenderingMethod renderingMethod) const
{
    auto expandedScaledSize = scaledImageBufferSize(size, scale);
    if (expandedScaledSize.isEmpty())
        return nullptr;

     auto clampingScale = clampingScaleForImageBufferSize(expandedScaledSize);

     auto imageBuffer = createImageBuffer(expandedScaledSize * clampingScale, colorSpace, renderingMode.value_or(this->renderingMode()), renderingMethod);
    if (!imageBuffer)
        return nullptr;

     imageBuffer->context().scale(clampingScale);

     // 'expandedScaledSize' is mapped to 'size'. So use 'expandedScaledSize / size'
    // not 'scale' because they are not necessarily equal.
    imageBuffer->context().scale(expandedScaledSize / size);
    return imageBuffer;
}

So rr289518 changed the behavior here to scale the size by the FloatSize 'scale' and always create the ImageBuffer with resolutionScale = 1. Moreover it handles the clamping and it scales the GraphicsContext of the ImageBuffer by 'scale'

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220224/f11bf45f/attachment-0001.htm>