[Webkit-unassigned] [Bug 108550] Add support for -webkit-background-blend-mode to chromium

[bugzilla-daemon at webkit.org]

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


Horia Olaru <olaru at adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olaru at adobe.com




--- Comment #2 from Horia Olaru <olaru at adobe.com>  2013-04-02 06:20:00 PST ---
I have taken the Skia blend mode enabling code from the latest patches in bug 100071, so one could say they are partially reviewed. Therefore, I'm not sure how we should go about this code.

What is added on top of that is changes to ImageSkia to take into account the blend mode, and a new test that goes through Image::drawPattern (which did not get called otherwise).

I also have a question. Skia relies on the SkPaint object to pass and read the blend/composite mode (setXfermodeMode). However, I noticed that the Image::draw* functions also receive a GraphicsContext object, which also has a reference to a PlatformGraphicsContext (returned by platformContext). For Skia, this is a PlatformContextSkia object. The GraphicsContext object has a setCompositeOperation function, which ultimately ends up calling the PlatformContextSkia::setXfermodeMode. However, I'm not sure if this xfer mode is ever actually read or used from somewhere, since the SkPaint object seems to be enough to pass in this mode to Skia.

I feel like I should call setCompositeOperation, so that the Skia graphics context it is in sync with the SkPaint mode, in case someone reads it in the future, but I would like another opinion on it. Is this API only there to conform to the GraphicsContext API? Because setCompositeOperation seems to be redundant (at least for Skia), so I might be missing something.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.