New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 664262 link

Starred by 1 user
Status: Assigned
Owner:
erikc...@chromium.org
Cc:
█ briander...@chromium.org
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Investigation: Case study of trivial_scrolling_page.html

Project Member Reported by erikc...@chromium.org, Nov 10 2016 
See https://docs.google.com/document/d/1YVO9FGRBF1RUsedU28H6P8lt9bDpOci0vi0CLSkFih8/edit# for a less-in-depth study. 

The page has a large amount of text, and uses requestAnimationFrame to scroll the document by 1px each frame. This requires about 4ms of processing each frame. This seems quite high for such a simple case where *theoretically* there should be no style recalculations, and almost no repaints/rasterization.

Comment 1 by erikc...@chromium.org, Nov 10 2016 

Looking at the trace from the document, IPCs and thread hops also seem to take more time than I would expect. Maybe this is tracing overhead? This would be a good place to do a most in-depth investigation about the cost of IPCs.

Comment 2 by erikc...@chromium.org, Nov 16 2016

Cc: briander...@chromium.org
brianderson notes that ProxyMain::BeginMainFrame::commit should show an "abort" task that prevents a commit. Instead, there is a PendingTree::Waiting which implies that a real commit is happening. This is not working as intended.
►

Sign in to add a comment