[Webkit-unassigned] [Bug 192471] New: [CG] Don't copy the ImageBuffer pixels data when drawing to an accelerated context

[bugzilla-daemon at webkit.org]

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

            Bug ID: 192471
           Summary: [CG] Don't copy the ImageBuffer pixels data when
                    drawing to an accelerated context
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Images
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: sabouhallawa at apple.com

This basically will roll out the change <http://trac.webkit.org/changeset/106095>.

ImageBuffer::copyNativeImage() has two copy behaviors:

1. DontCopyBackingStore: this passes a CGDataProvider to CGImageCreate() which is named m_data.dataProvider. The m_data.dataProvider holds the image pixels data which is named ‘m_data.data’. The same m_data.dataProvider is also backs the ImageBuffer context which is named ‘m_data.context’. Remember m_data.dataProvider is ref-counted pointer of type RetainPtr<CGDataProviderRef>.

2. CopyBackingStore: this passes the ‘m_data.context’ to CGBitmapContextCreateImage(). But this is actually does not copy the pixel data from the context. According to the documentation the returned CGImageRef follows copy-on-write semantics. That means it will copy the data only when the context changes. This does not include freeing the pixels data if the context was created by CGBitmapContextCreate().

The description of bug in https://bugs.webkit.org/show_bug.cgi?id=77185 says that “Thus, especially in the case of accelerated canvas there can be image tearing so we need to always do a deep copy if the destination context is accelerated.” So the worry was freeing the Image buffer not changing its contents. But this is confusing because DontCopyBackingStore is safer than CopyBackingStore in this regard. The image buffer may be deleted but its m_data.data will stay alive if there is a CGDataProvider referencing it.

-- 
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/20181206/5819d40a/attachment.html>