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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 11 11:38:31 PDT 2012


--- Comment #7 from Nat Duca <nduca at chromium.org>  2012-06-11 11:38:29 PST ---
(From update of attachment 146644)
View in context: https://bugs.webkit.org/attachment.cgi?id=146644&action=review

Gettin there! :)

>> Source/WebKit/chromium/public/WebWidget.h:227
>> +    virtual void renderingStats(WebRenderingStats&) { }
> this doesn't make sense on WebWidget - we only support compositing on WebViews.
> renderingStats() is a bit generic for what this is - since it's only for compositing mode, something compositor-specific in the name would be better.
> Looking at the implementation, it looks like this call is relatively heavy - it blocks the main thread until the compositor thread can respond. Someone looking at this header in isolation might think it's perfectly fine to do something like call this every frame just in case. I think we should document how expensive this call is or make it cheaper.

I think this makes sense on webwidget, actually. Fullscreen pepper plugins are webwidgets, remember? :/ And, we have teh composite() method on WebWidget.

obtainRenderingStats() with a comment saying it is slightly costly is sufficient for now, I think. THis is the place to explain that the call only works in accelerated mode and that calling it  in software mode will assert false.

> Source/WebKit/chromium/src/WebLayerTreeView.cpp:175
> +    stats.frameNumber = ccStats.frameNumber;

/me wonders out loud if we have an accepted technique for converting structs, e.g. by having the WebRenderingStats have conversion functions on it. Walk over to jamesr's desk and ask him if we have a way to do this cleaner please?

> Source/WebKit/chromium/src/WebViewImpl.cpp:1455
> +{

You should ASSERT_NOT_REACHED in the case that this is called in non-accelerated mode.

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

More information about the webkit-unassigned mailing list