When using the accelerated path, ImageBufferCairo creates up to two textures for rendering: m_texture to hold the buffer content, and m_compositorTexture used to take the content to the ThreadedCompositor (when enabled). These 2 textures are passed to cairo to create a cairo_surface using cairo_gl_surface_create_for_texture(), but cairo doesn't take their ownership, so currently they are not being destroyed when the ImageBuffer gets destroyed.
Created attachment 273958 [details] Patch
Comment on attachment 273958 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=273958&action=review > Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp:88 > + if (!m_texture) > + return; I assume m_texture has to be present for m_compositorTexture to be created, but it would be better not to count on that, and just either delete m_texture or m_compositorTexture if they are non-null. > Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp:90 > + GLContext::sharingContext()->makeContextCurrent(); This destructor should store the previous context and restore it when done, as we usually do. At some point, we should also use a separate offscreen context for the accelerated canvas, and not the sharing context. > Source/WebCore/platform/graphics/cairo/ImageBufferDataCairo.h:58 > + ~ImageBufferData(); This should be virtual.
(In reply to comment #2) > Comment on attachment 273958 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=273958&action=review > > > Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp:88 > > + if (!m_texture) > > + return; > > I assume m_texture has to be present for m_compositorTexture to be created, > but it would be better not to count on that, and just either delete > m_texture or m_compositorTexture if they are non-null. Yes, using an accelerated path m_texture must exist and m_compositorTexture may or may not. I'll simplify it. > > Source/WebCore/platform/graphics/cairo/ImageBufferCairo.cpp:90 > > + GLContext::sharingContext()->makeContextCurrent(); > > This destructor should store the previous context and restore it when done, > as we usually do. Ok. > At some point, we should also use a separate offscreen context for the > accelerated canvas, and not the sharing context. Agree. > > Source/WebCore/platform/graphics/cairo/ImageBufferDataCairo.h:58 > > + ~ImageBufferData(); > > This should be virtual. Ok.
Comment on attachment 273958 [details] Patch Attachment 273958 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/977298 New failing tests: js/function-apply.html
Created attachment 273974 [details] Archive of layout-test-results from ews114 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews114 Port: mac-yosemite Platform: Mac OS X 10.10.5
Created attachment 273983 [details] Patch
Comment on attachment 273983 [details] Patch LGTM. Will wait for the EFL EWS to build, and cq+ after that.
Comment on attachment 273983 [details] Patch Clearing flags on attachment: 273983 Committed r198205: <http://trac.webkit.org/changeset/198205>
All reviewed patches have been landed. Closing bug.