|Summary:||Garbage is displayed when root svg element has mix-blend-mode set|
|Component:||SVG||Assignee:||Said Abou-Hallawa <sabouhallawa>|
|Severity:||Normal||CC:||commit-queue, esprehn+autocc, glenn, kondapallykalyan, sabouhallawa, simon.fraser, webkit-bug-importer, zalan, zimmermann|
|Version:||WebKit Nightly Build|
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 4 Darin Adler 2016-01-24 21:11:59 PST
Comment on attachment 269719 [details] Patch 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] Patch This seems like the wrong approach. I think what's missing is a save/restore around setting the clip.
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] Patch 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.