[Webkit-unassigned] [Bug 174632] [GTK] Completely garbled display in Transifex in accelerated compositing mode

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=174632

--- Comment #7 from Miguel Gomez <magomez at igalia.com> ---
wow this was an extensive debug with an unexpected end.

So, when rendering the problematic svg image, drawing commands are being issued to the GrapgicsContext that are in the end sent to cairo.
The problematic command here is GraphicsContext::clipToImageBuffer, which is supposed to apply the content as an imageBuffer a mask for clipping the drawings after that. This is not supported in cairo. What is supported is rendering a surface content with an image mask. So what's done here is:

- save the current context status
- change the rendering target to a temporal one and save the image mask
- render to the temporal target
- when the context status is restored, render the temporal target contents into the original target using the saved image mask

In order to support these steps, there's a stack that stores context data every time the context is saved, and restores it when the context is restored. This is handled by PlatformContextCairo::save() and PlatformContextCairo::restore(). The image mask that has to be applied on restore() is also saved in that stack.

And here comes the funny thing. That stack is a WTF::Vector. As the vector grows there's a moment when it will move its contents to a bigger memory space. This move will use a constructor copy if available to move the stored data. But the class used to store the data in the stack has a copy constructor that doesn't copy the image mask. This causes that when the Vector reaches a concrete size and the items are moved, all the image masks stored there are lost.

Then, as there are no image masks to apply, restore doesn't change the rendering target from the temporal one to the original, which causes that nothing gets rendered.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170824/485b7215/attachment-0001.html>