RESOLVED FIXED 150556
Garbage is displayed when root svg element has mix-blend-mode set
https://bugs.webkit.org/show_bug.cgi?id=150556
Summary Garbage is displayed when root svg element has mix-blend-mode set
kari.pihkala
Reported 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).
Attachments
test file which has svg root element with mix-blend-mode (207 bytes, image/svg+xml)
2015-10-26 06:01 PDT, kari.pihkala
no flags
Patch (5.42 KB, patch)
2016-01-24 19:51 PST, Said Abou-Hallawa
no flags
Patch (6.30 KB, patch)
2016-01-26 18:54 PST, Said Abou-Hallawa
no flags
Another test case (391 bytes, image/svg+xml)
2016-01-26 18:55 PST, Said Abou-Hallawa
no flags
One more test case (401 bytes, image/svg+xml)
2016-01-26 20:12 PST, Said Abou-Hallawa
no flags
kari.pihkala
Comment 1 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.
Radar WebKit Bug Importer
Comment 2 2015-10-26 21:38:51 PDT
Said Abou-Hallawa
Comment 3 2016-01-24 19:51:52 PST
Darin Adler
Comment 4 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?
Simon Fraser (smfr)
Comment 5 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.
Said Abou-Hallawa
Comment 6 2016-01-26 18:54:46 PST
Said Abou-Hallawa
Comment 7 2016-01-26 18:55:26 PST
Created attachment 269968 [details] Another test case
Said Abou-Hallawa
Comment 8 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.
Said Abou-Hallawa
Comment 9 2016-01-26 20:12:13 PST
Created attachment 269978 [details] One more test case
WebKit Commit Bot
Comment 10 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>
WebKit Commit Bot
Comment 11 2016-01-27 18:21:38 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.