Bug 61700 – Need WebKit2 API to get the size of the render tree

• Component: WebKit API
• Status: RESOLVED FIXED

[Beth Dakin]

<rdar://problem/9512733>

We need a WebKit 2 API to get the size of the render tree.

Patch forthcoming.

[Beth Dakin]

Created attachment 95280 [details]
Patch

Right now this is set up to send the updated render tree size to the UI process in every FrameView::performPostLayoutTasks(). Then the value is cached in the UIProcess. While convenient, we may want to improve on this later to avoid sending so many messages. In the meantime, this does not have any measurable affect on performance.

[Simon Fraser (smfr)]

Comment on attachment 95280 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=95280&action=review

> Source/WebCore/page/ChromeClient.h:328
> +        virtual void setRenderTreeSize(size_t) { }

'size' is ambiguous: memory use, renderer count? A more explicit name would help.

> Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:801
> +    m_page->send(Messages::WebPageProxy::SetRenderTreeSize(treeSize));

Is there an existing message that we pass whose payload can be expanded to carry these data?

[Beth Dakin]

(In reply to comment #2)
> (From update of attachment 95280 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=95280&action=review
> 
> > Source/WebCore/page/ChromeClient.h:328
> > +        virtual void setRenderTreeSize(size_t) { }
> 
> 'size' is ambiguous: memory use, renderer count? A more explicit name would help.
> 

I'll think on this.

> > Source/WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:801
> > +    m_page->send(Messages::WebPageProxy::SetRenderTreeSize(treeSize));
> 
> Is there an existing message that we pass whose payload can be expanded to carry these data?

We could be mistaken (must consult Sam or Anders), but Geoff and I think CoreIPC automatically bundles small messages into one bigger message.

[Darin Adler]

Comment on attachment 95280 [details]
Patch

Patch looks fine. No obvious better terminology to use beyond “render tree size”. I could imagine more-abstract names or more-concrete names.

[Darin Adler]

Comment on attachment 95280 [details]
Patch

Clearing flags on attachment: 95280

Committed r87638: <http://trac.webkit.org/changeset/87638>

[Darin Adler]

All reviewed patches have been landed.  Closing bug.

[Darin Adler]

Half the patch wasn’t landed the first time.

Committed the other half as r87639: <http://trac.webkit.org/changeset/87639>

[Sam Weinig]

> We could be mistaken (must consult Sam or Anders), but Geoff and I think CoreIPC automatically bundles small messages into one bigger message.

CoreIPC doesn't have this functionality.  All messages get a mach message.