[Webkit-unassigned] [Bug 234653] New: On systems without CG support for alpha premultiplied gradients, the CGGradientRef path should still be used for the subset of gradients that can transformed

[bugzilla-daemon at webkit.org]

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

            Bug ID: 234653
           Summary: On systems without CG support for alpha premultiplied
                    gradients, the CGGradientRef path should still be used
                    for the subset of gradients that can transformed
           Product: WebKit
           Version: Other
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Platform
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sam at webkit.org

The current behavior of the CoreGraphics gradient drawing code path is to always use the CGShadingRef strategy for alpha premultiplied gradients if the system does not natively support alpha premultiplied gradients in the CGGradientRef code path.

For performance, we really would like to use the CGGradientRef code path as much as possible, as the backend has a better opportunity to optimize over the CGShadingRef code path.

Fortunately, there are a class of common gradients that can still use the CGGradientRef code path either totally unmodified or with a transformation of the color stops.

Any gradient that uses a uniform alpha value in all its color stops (e.g. linear-gradient(rgba(255, 0, 0, 0.5), rgba(0, 0, 255, 0.5)) can be used directly with no modification, as the alpha premultiplied and alpha non-premultiplied renderings are identical. 

Additionally, gradients that conform to the rule that "any two consecutive color stops must either have one that is fully transparent or have the same alpha value for both" can be transformed to be used by the alpha non-premultiplied backend via a transformation of the color stop list.

-- 
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/20211223/f239d617/attachment-0001.htm>