[chromium] Add entrypoints to set frame contents and recycle resources in WebDelegatedRendererLayer
Created attachment 167874 [details] Patch
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment on attachment 167874 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167874&action=review > Source/Platform/chromium/public/WebDelegatedRendererLayer.h:31 > +namespace cc { We can't have a "namespace cc" here. It looks like TransferableResourceList will have to be declared in WebKit namespace and put in Source/Platform/chromium/public/ .
We should find a way to do this. If you pull the thread, you'll end up moving all of cc back into webkit. We need a way to have opaque data flow untouched through the webkit API... Also, it would become a nightmare to have TransferedResource in a different repository as we add more resource types and transport mechanism (think shared memory etc.)
Comment on attachment 167874 [details] Patch Indeed.
> If you pull the thread, you'll end up moving all of cc back into webkit. > We need a way to have opaque data flow untouched through the webkit API... Typically we do this by exposing a type and then having the embedder subclass that type. See ExtraData in a number of the networking APIs.
Created attachment 167884 [details] Patch
FTR, I think it's sad to lose static typing for perceived purity of the API (who are we kidding really). But whatever you say.
(In reply to comment #8) > FTR, I think it's sad to lose static typing for perceived purity of the API (who are we kidding really). But whatever you say. jamesr might have a better idea, but that's the pattern we've used elsewhere. It does have the unfortunate issue of making the embedder static_cast, but at least it has no runtime cost.
Comment on attachment 167884 [details] Patch Attachment 167884 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/14223936
Comment on attachment 167884 [details] Patch Attachment 167884 [details] did not pass cr-android-ews (chromium-android): Output: http://queues.webkit.org/results/14252009
Created attachment 168080 [details] Patch
patch with non-pure-virtual methods to allow landing. Will remove in follow up when chrome side has landed.
Comment on attachment 168080 [details] Patch Clearing flags on attachment: 168080 Committed r130998: <http://trac.webkit.org/changeset/130998>
All reviewed patches have been landed. Closing bug.