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

Issue 647840 link

Starred by 1 user
Status: WontFix
Owner:
wangxianzhu@chromium.org
Closed: Nov 2016
Cc:
█ briander...@chromium.org
skyos...@chromium.org
enne@chromium.org
█ jaydasika@chromium.org
chrishtr@chromium.org
vmp...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug



Sign in to add a comment

FrameView::synchronizedPaint is very slow on docs.python.org

Project Member Reported by sunn...@chromium.org, Sep 16 2016 
On https://docs.python.org/2/library/re.html notice that the sidebar is never in sync with the content while scrolling. From tracing most of the time per frame is spent in FrameView::synchronizedPaint.

This on a Windows Z620 with Chrome ToT r419224

GN args:
is_component_build = true
is_debug = false
use_goma = true
symbol_level = 1
is_win_fastlink = true
dcheck_always_on = true
enable_nacl = false
ffmpeg_branding = "Chrome"
proprietary_codecs = true

This does not happen on Chrome Version 55.0.2862.0 canary (64-bit) r419063 although sync scrolling is still somewhat broken due to other reasons (issue 645284).

Attached traces for both ToT and canary.
trace_ToT_bug.json.gz
2.0 MB Download
trace_canary_no_bug.json.gz
2.3 MB Download

Comment 1 by sunn...@chromium.org, Sep 17 2016

Cc: briander...@chromium.org skyos...@chromium.org
Also captured a trace on Linux r418438 which also shows a similar problem. Look at the frames starting at ~2385ms, this is right after a scroll. A BeginMainFrame is sent but it's aborted by the main thread. After this each frame spends a lot of time in FrameView::synchronizedPaint. This happens for each run of consecutive frames after a scroll event.
trace_docs_python_org_linux.json.gz
2.2 MB Download

Comment 2 by schenney@chromium.org, Sep 21 2016

Owner: wangxianzhu@chromium.org
Status: Assigned (was: Untriaged)
The problem with the left panel is particularly bad for mouse wheel scrolling, and is covered in issue 645284. We are compositing the scrolling content on ToT, at least according to DevTools.

synchronizedPaint is just the new painting pipeline, so it's not clear to me that this is a bug, rather than us just re-rastering something that we need to re-raster.

Assigning to wangxianzhu@ to determine if there is anything actionable here.

Comment 3 by chrishtr@chromium.org, Nov 8 2016

Status: WontFix (was: Assigned)
The paints are taking 1-2ms on my MacBook pro, which is in line with what I would
have expected for a page of this complexity. I don't think there is anything
particularly out of line about the paint performance on this page.

For the record, also note that on M54 this page exhibits  issue 655941 , which was fixed and
merged into M55.
►

Sign in to add a comment