Bug 150556

Summary: Garbage is displayed when root svg element has mix-blend-mode set
Product: WebKit Reporter: kari.pihkala
Component: SVGAssignee: Said Abou-Hallawa <sabouhallawa>
Severity: Normal CC: commit-queue, esprehn+autocc, glenn, kondapallykalyan, sabouhallawa, simon.fraser, webkit-bug-importer, zalan, zimmermann
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Description Flags
test file which has svg root element with mix-blend-mode
Another test case
One more test case none

Description kari.pihkala 2015-10-26 06:01:41 PDT
Created attachment 264043 [details]
test file which has svg root element with mix-blend-mode

If the mix-blend-mode css property has been set to something else than "normal" in the root svg element, then the page displays garbage (possibly unallocated memory?).

Steps to reproduce:

1. Open the attached mixblend.svg file in the browser
2. Resize the browser window to see garbage

I expect to see a yellow rectangle with a white page background, not garbage.

Tested Safari 9.0.1 and Webkit nightly (10601.2.7.2, r191553).
Comment 1 kari.pihkala 2015-10-26 07:14:43 PDT
> (possibly unallocated memory?)

I meant uninitialized :)  Also, the svg document needs to be opened as a top level document.
Comment 2 Radar WebKit Bug Importer 2015-10-26 21:38:51 PDT
Comment 3 Said Abou-Hallawa 2016-01-24 19:51:52 PST
Created attachment 269719 [details]
Comment 4 Darin Adler 2016-01-24 21:11:59 PST
Comment on attachment 269719 [details]

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

> Source/WebCore/ChangeLog:15
> +        In SVGRenderingContext::prepareToRenderSVGContent(), the clip() is called
> +        before beginTransparencyLayer() which calls save(). We need to move this
> +        call after the call to beginTransparencyLayer() to ensure the clipping will
> +        be restored to its previous state when endTransparencyLayer() is called in
> +        the destructor of SVGRenderingContext.

This is surprising.

I thought that:

1) setting a clip before calling beginTransparencyLayer reduces the amount of memory that has to be allocated in order to create a transparency layer
2) endTransparencyLayer does not guarantee a restore

I was probably wrong about (2), but was I wrong about (1)? Can we just add another save/restore instead?
Comment 5 Simon Fraser (smfr) 2016-01-25 11:19:57 PST
Comment on attachment 269719 [details]

This seems like the wrong approach. I think what's missing is a save/restore around setting the clip.
Comment 6 Said Abou-Hallawa 2016-01-26 18:54:46 PST
Created attachment 269967 [details]
Comment 7 Said Abou-Hallawa 2016-01-26 18:55:26 PST
Created attachment 269968 [details]
Another test case
Comment 8 Said Abou-Hallawa 2016-01-26 19:01:03 PST
Yes I took a wrong approach in the previous patch.

I was trying that patch on WK1 with test cases which do not force compositing. These test cases did not produce the bug with or without the patch.
Comment 9 Said Abou-Hallawa 2016-01-26 20:12:13 PST
Created attachment 269978 [details]
One more test case
Comment 10 WebKit Commit Bot 2016-01-27 18:21:34 PST
Comment on attachment 269967 [details]

Clearing flags on attachment: 269967

Committed r195724: <http://trac.webkit.org/changeset/195724>
Comment 11 WebKit Commit Bot 2016-01-27 18:21:38 PST
All reviewed patches have been landed.  Closing bug.