In https://trac.webkit.org/changeset/251836/webkit DataSegment was used over SharedBuffer because SharedBuffer didn't use thread-safe refcounting. However, since bug 230662, this is no longer the case. Once bug 233030 lands, SharedBuffer becomes immutable once created and can be shared across threads. ScalableImageDecoder currently takes a SharedBuffer, flatten it through the call to SharedBuffer::data() and then take a reference to the inner DataSegment. ScalableImageDecoder should be re-written to use SharedBuffer so that we can do without the copy/memory allocation required by the flattening of the SharedBuffer.
<rdar://problem/85854204>
Created attachment 447874 [details] Patch
Created attachment 447909 [details] Patch rebase
Created attachment 447912 [details] Test Checking that those errors aren't happening with unpatched tree.
Created attachment 447924 [details] Patch Use DataSegment for ImageBackingStore
Comment on attachment 447924 [details] Patch If SharedBuffer is intrinsically immutable, then I think we should be using RefPtr<SharedBuffer> rather than RefPtr<const SharedBuffer>. Saying const all the time doesn’t have any meaning, right?
(In reply to Darin Adler from comment #6) > Comment on attachment 447924 [details] > Patch > > If SharedBuffer is intrinsically immutable, then I think we should be using > RefPtr<SharedBuffer> rather than RefPtr<const SharedBuffer>. Saying const > all the time doesn’t have any meaning, right? SharedBuffer still does have non const method such as takeData and in bug 232424 all SharedBuffer are passed as const SharedBuffer& By making it a RefPtr<const SharedBuffer> I can remove all the required const cast when taking a strong reference to that buffer
Committed r287507 (245642@main): <https://commits.webkit.org/245642@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 447924 [details].