While working on bug #161242 I've realized that having the view port controller in the compositing thread makes everything more complex. The viewport controller receives changes about things like contents size, viewport size, etc. and uses that information to compute the visible contents rect and page scale factor. Then it notifies back to main thread about the computed visible contents rect and page scale. Those computations are not heave at all, so they could be done in the main thread and we would avoid communications between the main and compositing thread in both directions. The main thread needs the visible contents rect to notify the compositing coordinator and the page cale to scale the page in case of pixed layout. But the compositing thread only needs to know the effective scale and scroll position. So, instead of going to the compositing thread after every change that might update the visible contents rect and page scale factor, we could do those calculations in the main thread and only notify the compositing thread about the actual changes in the scroll position and effective scale.
Created attachment 287757 [details] Patch
Comment on attachment 287757 [details] Patch Attachment 287757 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1994219 New failing tests: imported/w3c/web-platform-tests/fetch/api/cors/cors-preflight-redirect.html
Created attachment 287761 [details] Archive of layout-test-results from ews116 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews116 Port: mac-yosemite Platform: Mac OS X 10.10.5
Committed r205395: <http://trac.webkit.org/changeset/205395>