Bug 98833 – [chromium] Add entrypoints to set frame contents and recycle resources in WebDelegatedRendererLayer

• Component: New Bugs
• Status: RESOLVED FIXED

[Antoine Labour]

[chromium] Add entrypoints to set frame contents and recycle resources in WebDelegatedRendererLayer

[Antoine Labour]

Created attachment 167874 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail], [e-mail], [e-mail], [e-mail] or [e-mail] before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.

[Alexandre Elias]

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/ .

[Antoine Labour]

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.)

[Adam Barth]

Comment on attachment 167874 [details]
Patch

Indeed.

[Adam Barth]

> 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.

[Antoine Labour]

Created attachment 167884 [details]
Patch

[Antoine Labour]

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.

[Adam Barth]

(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.

[WebKit Review Bot]

Comment on attachment 167884 [details]
Patch

Attachment 167884 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/14223936

[Peter Beverloo (cr-android ews)]

Comment on attachment 167884 [details]
Patch

Attachment 167884 [details] did not pass cr-android-ews (chromium-android):
Output: http://queues.webkit.org/results/14252009

[Antoine Labour]

Created attachment 168080 [details]
Patch

[Antoine Labour]

patch with non-pure-virtual methods to allow landing. Will remove in follow up when chrome side has landed.

[WebKit Review Bot]

Comment on attachment 168080 [details]
Patch

Clearing flags on attachment: 168080

Committed r130998: <http://trac.webkit.org/changeset/130998>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.