[Webkit-unassigned] [Bug 273239] [Skia] Fix corner cases involving drawing shadows

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Apr 25 03:32:21 PDT 2024


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

--- Comment #2 from Pawel Lampe <plampe at igalia.com> ---
In general the above failures are due to 2 distict problems:

1) Skia bug when drawing an image with a shadow filter:

Currently, when we draw an image with shadow, we do this using a single call:
m_canvas.drawImageRect(image, normalizedSrcRect, normalizedDestRect, toSkSamplingOptions(m_state.imageInterpolationQuality()), &paint, { });
which uses a paint (SkPaint) with SkImageFilters::DropShadow attached using paint.setImageFilter(). While this works in most of the cases, it turns out that sometimes - when SkImageFilters::DropShadow is attached, and the <canvas> size is very close to the size of image being drawn - the above call draws no shadow (or nothing if I recall correctly). So far I've observed that it happens only when the image we're drawing is using accelerated surface, so e.g. if we uncomment the line in below demo (and comment the one above) the issue is gone:

<html>
  <head>
  </head>
  <body>
    <img id="img" src="/images/red.png" style="visibility:hidden">
    <canvas id="canvas" width="166" height="99" style="border: 1px solid #000"/>
    <script>
      var img = document.getElementById("img");
      img.onload = async () => {
          var canvas = document.getElementById("canvas");
          var ctx = canvas.getContext('2d');

          ctx.fillStyle = '#00f';
          ctx.fillRect(0, 0, 100, 50);
          ctx.shadowColor = '#0f0';
          ctx.shadowOffsetY = 50;
          var x = await createImageBitmap(img);
          // var x = img;
          ctx.drawImage(x, 0, -25);
      }
    </script>
  </body>
</html

the red.png comes from LayoutTests/imported/w3c/web-platform-tests/



2) Every time we draw something with a shadow, we do it within a single draw call with shadow filter attached.

While this approach is very clean and efficient, it makes it impossible to handle cases where the certain class of composite operators come into play. More precisely, the operators such as "destination-atop" etc. assume that drawing of e.g. rect with shadow is done in 2 steps: first draw the shadow, then the rect. In such case, having composite operation such as "destination-atop" would make the shadow to appear over the rect since shadow was on canvas before rect, and therefore it serves as a "desitnation" when rect is being drawn.

-- 
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/20240425/2e514600/attachment-0001.htm>


More information about the webkit-unassigned mailing list