New issue
Advanced search Search tips

Issue 794373 link

Starred by 3 users
Status: Assigned
Owner:
ccameron@chromium.org
Cc:
danakj@chromium.org
behdad@chromium.org
tapted@chromium.org
rbasuvula@chromium.org
drott@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Poor text rendering performance of wikipedia page

Project Member Reported by shrike@chromium.org, Dec 13 2017 
Chrome Version: 65.0.3287.0
OS: macOS 10.12

What steps will reproduce the problem?
(1) Load the attached .html file, which is a captured wikipedia page that includes code to continually fast-scroll the page

What is the expected result?
Renderer CPU usage should be on par with Safari 11.0.1, which clocks in around 8% of a core.

What happens instead?
Chrome's renderer consumes ~30% CPU, around 4x Safari. In both cases window server CPU comes in around 20%.

(For the record, the GPU and browser processes combined consume an additional 17%, which is problem above and beyond the renderer.)

I have attached the following:

  * An Instruments trace of the Chrome renderer process
  * A text file with stack frame info copy/pasted from the Instruments trace
  * A trace from Safari's renderer
  * The .html test file

Looking at the Safari trace it seems like Safari must set up all the data structures needed to scroll the page and reuse them (perhaps stuffing them in a CALayer). blink is doing a lot of work in its Paint system to draw the text, and is perhaps creating the same CTTypesetters and CFAttributedStrings over and over again.
WikipediaCatScroll.trace.zip
2.3 MB Download
wikipedia-cat-scroll-trace.zip
14.7 KB Download
safari-wikipedia-cat-scroll.zip
34.6 KB Download
wiki-cat-scroll-fast.html.zip
137 KB Download

Comment 1 by dtapu...@chromium.org, Dec 13 2017 

shrike@ are you going to own this?

Just wondering from a triage sheriff point of view who this issue should goto first as you've set a pretty generic component with "Blink".

Comment 2 by shrike@chromium.org, Dec 13 2017 

Hello dtapuska@,

I didn't see a better choice for triage queue than Blink (was hoping for Blink>Text).

I was hoping to get at least some insight from Blink-land about the reasons for the performance problems and thoughts about how they might be addressed.

Comment 3 by dtapu...@chromium.org, Dec 13 2017

Components: -Blink Internals>Compositing Internals>GPU
Over to Internals>Compositing/Internals>GPU.

A chrome trace shows that minimal time is spent inside blink adjusting the scroll position with the bulk of the work happening on the GPU and the compositor.

Comment 4 by danakj@chromium.org, Dec 15 2017

Cc: -ccameron@chromium.org
Labels: -Pri-3 Pri-2
Owner: ccameron@chromium.org
Status: Assigned (was: Untriaged)
Chris, is this a regression maybe?

https://bugs.chromium.org/p/chromium/issues/detail?id=784736 reported janky scrolling on High Sierra that might be the same thing.

I tried opening traces in about:tracing but they were not valid?

Comment 5 by danakj@chromium.org, Dec 15 2017 

shrike can you give your about:gpu when you reproduce this also?

Comment 6 by danakj@chromium.org, Dec 19 2017

Cc: tapted@chromium.org danakj@chromium.org rbasuvula@chromium.org
 Issue 784736  has been merged into this issue.

Comment 7 by tapted@chromium.org, Dec 20 2017

Cc: behdad@chromium.org drott@chromium.org
Note wrt the CTTypesetters and CFAttributedStrings stuff. Blink should be caching text runs (ShapeCache.cpp). I waited a couple of scroll iterations and sampled  - the CTTypesetterCreateWithAttributedStringAndOptions stuff drops off noticeably, but not completely. There might be something to investigate there.

Comment 8 by ccameron@chromium.org, Dec 20 2017 

I don't think this is a regression -- we use more CPU power than Safari in general -- somehow we use lower GPU power and that makes us hit parity.

I suspect that this is the general "we need the compositor to not copy the world around every frame" issue that we discussed a while ago.

Comment 9 by shrike@chromium.org, Jan 2 2018 

Attaching about:gpu.
aboutgpu.htm
65.1 KB View Download

Comment 10 by ccameron@chromium.org, Jan 10 2018 

Re #8, my initial experiments indicate that copying the world costs less than I thought :/
►

Sign in to add a comment