Each call to FilterEffect::effectContext() allocates a new m_effectBuffer

• Component: SVG
• Status: RESOLVED WORKSFORME

[Simon Fraser (smfr)]

m_effectBuffer is allocated each time FilterEffect::effectContext() is called. Adding this assertion:


diff --git a/WebCore/platform/graphics/filters/FilterEffect.cpp b/WebCore/platform/graphics/filters/FilterEffect.cpp
index c228731..3f8f099 100644
--- a/WebCore/platform/graphics/filters/FilterEffect.cpp
+++ b/WebCore/platform/graphics/filters/FilterEffect.cpp
@@ -77,6 +77,8 @@ GraphicsContext* FilterEffect::effectContext()
     determineAbsolutePaintRect();
     if (m_absolutePaintRect.isEmpty())
         return 0;
+
+    ASSERT(!m_effectBuffer);
     m_effectBuffer = ImageBuffer::create(m_absolutePaintRect.size(), ColorSpaceLinearRGB);
     if (!m_effectBuffer)
         return 0;

shows that this indeed happens for at least one layout test:

svg/filters/feBlend-invalid-mode.xhtml -> crashed
ASSERTION FAILED: !m_effectBuffer

[Balazs Kelemen]

I don't know much about that code path but this is definitely not a leak
since m_effectBuffer is an OwnPtr.

[Dirk Schulze]

I'll also take a look at this later. Still a bit busy right now.

[Simon Fraser (smfr)]

Update title. The behavior still seems wrong.

[Zoltan Herczeg]

If I ever get an r+, this will be fixed in:
https://bugs.webkit.org/show_bug.cgi?id=49907

[Dirk Schulze]

(In reply to comment #4)
> If I ever get an r+, this will be fixed in:
> https://bugs.webkit.org/show_bug.cgi?id=49907

Ah, so it is because of the multiple apply() calls of an effect?

[Zoltan Herczeg]

> Ah, so it is because of the multiple apply() calls of an effect?

Exactly. Example:

  <feA result="a" />
  <feB in="a" result="b" />
  <feC in="a" result="c" />
  <feComposite in="b" in2="c">

In this case the apply() of feA was called twice, and the result was generated twice before. This is unnecessary (and usually costly).

[Zoltan Herczeg]

Fixed in r73894 ( https://bugs.webkit.org/show_bug.cgi?id=49907 ).