cc: Long UIResource requests during tree activation (on Mac) |
|
Issue descriptionChrome Version: 66.0.3329.1 OS: OSX 10.12.6 & 10.13.2 tested What steps will reproduce the problem? (1) Open https://colab.research.google.com/notebook#fileId=14IvSaLNrBYrMLwjFTcvSufJWGIKPNFs_ (2) Resize browser window such that code blocks in the Colab Notebook don't fit and get horizontal scroll bars. (3) Scroll up & down. I first noticed the issue on a 2012 MBP Retina with 8GB of RAM, with a Colab Notebook I was working on, but and had a harder time reproducing on a 16GB MBP. The linked example Notebook above adds a lot of extra code blocks which also provoke the issue on a 2015 MBP with 16GB RAM, though it is still much faster on the latter. Extra notes are in this shared doc: https://docs.google.com/document/d/159ha6FsmtoawZola13vlf5iRR4chvDl5YcP0Uzb6lys The CC thread is mostly waiting for GPU Memory Buffer and GPU Command Buffer IPCs, while GPU thread is pegged creating and uploading the UI resources.
,
Jan 23 2018
(also point 3 in #1 will allow further sandbox lockdown, avoid messiness in impl-side-scrolling, and generally make for less sadness)
,
Jan 23 2018
> 1. It may be worth investigating if doing one-copy anonymous-GMB GLImages has a > better power profile than zero-copy. This is low priority b/c SW raster is so > rare. I think we are doing that in this case; rather than zero-copy we're using TexStorage2DImageCHROMIUM + TexSubImage2D. Though, we're not using staging GMBs like for one-copy raster. This should be asynchronous, but it looks like there are a lot of Flushes & WaitForTokens happening (nearly one per TexStorage2DImageCHROMIUM), so it would be interesting to see why that is. Rather than explicit, it may be that we're just running out of transfer buffer space. We don't scale that up very aggressively to prevent stalls. The service side TexSubImage2D are still slow (esp. on the GT 650M on my 2012 MBP). > 3. Mac team also really should stop calling into these private APIs to > draw scrollbars, etc -- we already have code to draw them in Skia for > MacViews, we just need to hook that up. It would be interesting to understand what causes us to invalidate and re-upload all these resources. (a) They should not be changing and (b) They're mostly out of view. |
|
►
Sign in to add a comment |
|
Comment 1 by ccameron@chromium.org
, Jan 23 2018