[Webkit-unassigned] [Bug 88268] [chromium] Expose rendering statistics to WebLayerTreeView.

[bugzilla-daemon at webkit.org]

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





--- Comment #32 from Adam Barth <abarth at webkit.org>  2012-06-21 19:16:31 PST ---
> Ignoring the fact that the actual value() implementaiton is in the header rather than an impl file in src for a moment, can we get your advice on the following basic design problem?

Sorry.  Sorry for being brief earlier.  I was a bit rushed.

> We have a webkit-side data structure with stats in it. We want to export that data structure to javascript, but the interface out to JS is via a chrome-side extension, e.g. content/renderer/gpu/gpu_benchmarking_extension. That extension calls into webview to get the rendering stats structure, converts it to a v8::value and returns it out to javascript. The chromium-side code does not need to do anything with this data structure, just get it into v8.

Got it.

> The thing I'm trying to avoid is us having to make a change to chromium every time we change this webkit-side data. E.g. if I add a field, I want to avoid having to also change the v8 serialization code of this structure in chrome. Or, similarly, if I change a field, having to do a 3 way set of commits to make the change happen.
> 
> SerializedScriptValue is promising here because it allows us to exchange values between webkit and a chrome-side v8 extension without the chrome side having to do the WebType->v8 serialization.
> 
> Any alternative ideas on how to do this?

The fact that you're exposing this data structure to the GPU benchmarking extension in an implementation detail of Chromium that should be hidden from WebKit.  From WebKit's perspective, this data structure is just like many of other data structures we exchange with the embedder that aren't translated into JavaScript APIs in Chromium.

One trick we could try is to create a macro that iterates over all the properties of the data structure.  Chromium could then use this macro to generate JavaScript bindings.  We use this trick internally in WebCore a bunch, but I don't think we've ever used it in the API.  If that sounds appealing, we should check with the other API reviewers to make sure they're happy with it.

> Note, this is based on the WebIDBCursor::value design, which seems to do the same basic thing, but with the caveat that the chromium-side code is in src/webkit/glue and thus able to access WebKit/chromium/platform --- content/ doesn't seem to be able to see this directory. ~puzzled hat~

My understanding is that we're going to remove the use of WebSerializedScriptValue in WebIDBCursor::value in favor of just using WebData.  From Chromium's perspective, it's just an opaque sequence of bytes.  WebCore happens to interpret those bytes as a serialized script value, but Chromium doesn't care about that.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.