<rdar://problem/9512733> We need a WebKit 2 API to get the size of the render tree. Patch forthcoming.
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.
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?
(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.
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.
Comment on attachment 95280 [details] Patch Clearing flags on attachment: 95280 Committed r87638: <http://trac.webkit.org/changeset/87638>
All reviewed patches have been landed. Closing bug.
Half the patch wasn’t landed the first time. Committed the other half as r87639: <http://trac.webkit.org/changeset/87639>
> 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.