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

Issue 624630 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Sep 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Regression



Sign in to add a comment

102.9% regression in memory.blink_memory_mobile/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg on android-nexus5X at 402675:402715

Project Member Reported by bashi@chromium.org, Jun 30 2016

Issue description

Performance dashboard identified a 102.9% regression in memory.blink_memory_mobile/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg on android-nexus5X at revision range 402675:402715. Graph: https://chromeperf.appspot.com/group_report?keys=agxzfmNocm9tZXBlcmZyFAsSB0Fub21hbHkYgICg4pSTsgoM

 

Comment 1 by bashi@chromium.org, Jun 30 2016

Cc: bashi@chromium.org
 Issue 624629  has been merged into this issue.
Project Member

Comment 2 by 42576172...@developer.gserviceaccount.com, Jun 30 2016

Cc: vmi...@chromium.org
Owner: vmi...@chromium.org

=== Auto-CCing suspected CL author vmiura@chromium.org ===

Hi vmiura@chromium.org, the bisect results pointed to your CL below as possibly
causing a regression. Please have a look at this info and see whether
your CL be related.


===== BISECT JOB RESULTS =====
Status: completed


===== SUSPECTED CL(s) =====
Subject : Re-enable GPU Rasterization for content with any author defined viewport.
Author  : vmiura
Commit description:
  
BUG= 591179 

Review-Url: https://codereview.chromium.org/2097413003
Cr-Commit-Position: refs/heads/master@{#402702}
Commit  : a017b667a53b3ee5f8bc630be98c37ebf53a2339
Date    : Wed Jun 29 03:37:05 2016


===== TESTED REVISIONS =====
Revision         Mean     Std Dev  N  Good?
chromium@402674  4418066  114268   5  good
chromium@402695  4418805  96314.4  5  good
chromium@402700  4410923  112899   5  good
chromium@402701  4466541  139393   5  good
chromium@402702  9043552  61250.2  5  bad    <--
chromium@402703  9000909  58879.9  5  bad
chromium@402705  8991434  65902.7  5  bad
chromium@402715  9034866  32702.7  5  bad

Bisect job ran on: android_nexus5X_perf_bisect
Bug ID: 624630

Test Command: src/tools/perf/run_benchmark -v --browser=android-chromium --output-format=chartjson --upload-results --also-run-disabled-tests memory.blink_memory_mobile
Test Metric: memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg/memory:chrome:renderer_processes:reported_by_chrome:skia:effective_size_avg
Relative Change: 104.50%
Score: 99.9

Buildbot stdio: http://build.chromium.org/p/tryserver.chromium.perf/builders/android_nexus5X_perf_bisect/builds/268
Job details: https://chromeperf.appspot.com/buildbucket_job_status/9008471752272074416


Not what you expected? We'll investigate and get back to you!
  https://chromeperf.appspot.com/bad_bisect?try_job_id=5729269683060736

| O O | Visit http://www.chromium.org/developers/speed-infra/perf-bug-faq
|  X  | for more information addressing perf regression bugs. For feedback,
| / \ | file a bug with component Tests>AutoBisect.  Thank you!

Comment 3 by vmi...@chromium.org, Jun 30 2016

Cc: primiano@chromium.org ericrk@chromium.org
Thanks for the alert.  What does this test measure?
This measures amount of memory reported by skia in the renderer.
You can eyeball the traces for the facebook page before and after here (Traces collected by the bot):

before: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_1-2016-06-28_20-33-45-42862.html

after: https://console.developers.google.com/m/cloudstorage/b/chrome-telemetry-output/o/trace-file-id_1-2016-06-28_21-59-42-85943.html

If you look at the trace column there are a bunch (17 MB) of gpu resources reported under skia (they seem textures). The interesting thing is that they seem "purgeable" (it has a purgeable_size column). Not sure what that means, I am not a skia expert.

See attached screenshot.
Screen Shot 2016-06-30 at 10.57.55 AM.png
167 KB View Download

Comment 5 by ericrk@chromium.org, Jun 30 2016

Purgeable in Skia means that we *could* free the memory (it's not being actively used) - but that doesn't mean we should - if we use the memory quickly each frame, it will still be purgeable for the majority of the frame.

That said, when moving from something like SW to GPU raster, I don't think that a super specific metric like this is too interesting. This just means that Skia started using more memory - however, it doesn't take into account improvements in other areas (I would expect that tile memory was reduced).

If you look at some other areas, it looks like we had a reduction in both cc::efective_Size_avg and discardable:locked_size_avg (discardable is really noisy, but all spikes have disappeared since the patch landed). We see regressions in gpu::effective_size_avg and skia:effective_size_avg.

It looks like there may still be a slight regression - however it's not really at the scale indicated here.

Comment 6 by ericrk@chromium.org, Jun 30 2016

Ah, looked at the facebook traces included here (these show a worse regression than the overall telemetry trend) - in these we are definitely using more memory.

Looking at the Skia objects, which are perfectly sized (512k, 1024k, 2048K and 4096k) - my guess is that these are temprorary buffers used by Skia in rendering. It may be that we need to more aggressively clean up these resources?

It also looks like we use a bit more GPU memory for images in CC - if we purged unused images after X frames, we could likely drive this number down. I had been avoiding doing this, as this will hurt performance, and if we have the memory, it seems like we should use it?

Comment 7 by bashi@chromium.org, Jul 1 2016

FYI, you don't need to care about "purgeable_size" but you should care about "effective_size" because it's designed to represent actual amount of memory used by a component (in this case, skia).

I think using more memory is fine if we have enough and there is certain improvement on other metrics but I'd like to see the clarification.

Comment 8 by bashi@chromium.org, Jul 7 2016

vmiura@: any update?
I believe vmiura@ is OOO this week and next. He can give probably give more info, but from previous conversations I remember that this change results in an improvement to (non-webview) system health metrics. Primiano, do you recall the numbers here?

Additionally, as I pointed out in #5, I think that looking at this as a large regression is misleading. Looking at Skia in isolation doesn't tell us the full story for a large change like this, as the change effects a number of categories. If we look at overall renderer effective size (https://chromeperf.appspot.com/report?sid=388adafd8a3310bc7e668538a744cf537c33289615ae5698c45e6e782f28036e), we see a regression from about 150MB to 155MB  - this is only about a 3.3% regression. Even on Facebook, which shows the bad Skia regression posted above, overall renderer effective size only changes from ~217MB to ~232MB, a 6.5% regression.

So it seems like we should likely be treating this as a small (~5%) regression.

If we did want to improve things, we could cause Skia or Image Decode Controller to more aggressively evict not-recently-used resources. This would lower memory usage, but would also hurt performance the next time raster was required.

Thanks ericrk@ for the reply.

I understand your point but I'm uneasy to think this kind of regressions as small. 3-7% regression of total memory usage is huge. I don't think it's acceptable without having *strong* improvement on other numbers. I'd like to see the actual improvement.
Issue 629498 has been merged into this issue.
Cc: tdres...@chromium.org
@ericrk @bashi:

Note that the regression is not limited to memory metrics and impacts input and frame times on NYTimes, mlb.com, and youtube on nexus devices
- 300% regression in first_gesture_scroll_update_latency for NYTimes
- 75% regress in mean_input_event_latency  for NYtimes
- 40% regress in mean_input_event_latency  for mlb.com

I am not sure why that is. Naively I would have thought GPU rasterization would have positive impact on these metrics as it reduces load on CPU. 
Cc: picksi@chromium.org
 Issue 629502  has been merged into this issue.
majidvp@, thanks for the additional info!

Which graphs are showing the first_gesture_scroll_update_latency issues and mean_input_event_latency issues you mention? I'm looking at smoothness.key_mobile_sites_smooth and am seeing some changes, but not exactly what you describe - want to make sure we're looking at the same thing - have these changes/graphs been associated with a bug?
Cc: majidvp@chromium.org
+majidvp@ for the above question. Thanks!.
 Issue 629505  has been merged into this issue.
Status: Assigned (was: Untriaged)
Owner: ericrk@chromium.org
Status: Started (was: Assigned)
Have a fix in progress for this.
crrev.com/2286873003 is a prerequesite for the fix - submitted:

Provide TaskRunner to ContextCacheController

Both ContextCacheController and the CommandBuffer/GpuControl need
access to a TaskRunner. CommandBuffer/GpuControl currently creates this
TaskRunner internally in most cases. This change moves TaskRunner
creation to the ContextProvider, allowing the same TaskRunner to be
passed to both objects.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Committed: https://crrev.com/d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e
Cr-Commit-Position: refs/heads/master@{#419553}
Project Member

Comment 21 by bugdroid1@chromium.org, Sep 22 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/051ae83bf29b52cefd82235ebfb90f203912afbb

commit 051ae83bf29b52cefd82235ebfb90f203912afbb
Author: ericrk <ericrk@chromium.org>
Date: Thu Sep 22 23:20:23 2016

Idle cleanup for worker context

Currently, Skia flushes unused items out of its caches after ~1 second
of non-use (50 flushes). This works fine while Skia is in-use, but when
a worker context goes idle we stop calling into Skia altogether. This
means that Skia will never flush out unused cache items from the last
piece of work it did. This can lead to some rather large temporaries
being kept around (~20mb).

This change adds an idle cleanup process which flushes Skia's caches
and cleans up worker context resources after a worker context is idle
for 1 second.

BUG= 624630 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2353033003
Cr-Commit-Position: refs/heads/master@{#420496}

[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/BUILD.gn
[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller.cc
[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller.h
[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_cache_controller_unittest.cc
[add] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_provider.cc
[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/cc/output/context_provider.h
[modify] https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb/content/common/gpu/client/context_provider_command_buffer.cc

Labels: Merge-Request-54
With #21 landed this has changed from a large regression to a medium improvement. Seeing ~1.5MB savings on this metric across all bots (compared to pre-regression numbers).
This is great! I wish all regressions ended in such significant savings :)
Project Member

Comment 24 by bugdroid1@chromium.org, Sep 23 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c

commit a5ce62a749a47a57f8b3b2734eea4cec31e39d9c
Author: ericrk <ericrk@chromium.org>
Date: Fri Sep 23 21:51:37 2016

Revert of Idle cleanup for worker context (patchset #5 id:200001 of https://codereview.chromium.org/2353033003/ )

Reason for revert:
This appears to be breaking some number of unittests - need to investigate further.

Original issue's description:
> Idle cleanup for worker context
>
> Currently, Skia flushes unused items out of its caches after ~1 second
> of non-use (50 flushes). This works fine while Skia is in-use, but when
> a worker context goes idle we stop calling into Skia altogether. This
> means that Skia will never flush out unused cache items from the last
> piece of work it did. This can lead to some rather large temporaries
> being kept around (~20mb).
>
> This change adds an idle cleanup process which flushes Skia's caches
> and cleans up worker context resources after a worker context is idle
> for 1 second.
>
> BUG= 624630 
> CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel
>
> Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb
> Cr-Commit-Position: refs/heads/master@{#420496}

TBR=danakj@chromium.org,jbauman@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 624630 

Review-Url: https://codereview.chromium.org/2366033002
Cr-Commit-Position: refs/heads/master@{#420741}

[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/BUILD.gn
[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller.cc
[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller.h
[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_cache_controller_unittest.cc
[delete] https://crrev.com/a11540e8d7eb302bcef2f7c9010da5f693071035/cc/output/context_provider.cc
[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/cc/output/context_provider.h
[modify] https://crrev.com/a5ce62a749a47a57f8b3b2734eea4cec31e39d9c/content/common/gpu/client/context_provider_command_buffer.cc

Comment 25 by dimu@chromium.org, Sep 24 2016

Labels: -Merge-Request-54 Merge-Approved-54 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M54 (branch: 2840)
Project Member

Comment 26 by bugdroid1@chromium.org, Sep 27 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6714c23b526197220d8b9abdbd38b6d9c206d912

commit 6714c23b526197220d8b9abdbd38b6d9c206d912
Author: ericrk <ericrk@chromium.org>
Date: Tue Sep 27 03:35:01 2016

Idle cleanup for worker context

Currently, Skia flushes unused items out of its caches after ~1 second
of non-use (50 flushes). This works fine while Skia is in-use, but when
a worker context goes idle we stop calling into Skia altogether. This
means that Skia will never flush out unused cache items from the last
piece of work it did. This can lead to some rather large temporaries
being kept around (~20mb).

This change adds an idle cleanup process which flushes Skia's caches
and cleans up worker context resources after a worker context is idle
for 1 second.

BUG= 624630 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg

Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb
Review-Url: https://codereview.chromium.org/2353033003
Cr-Original-Commit-Position: refs/heads/master@{#420496}
Cr-Commit-Position: refs/heads/master@{#421092}

[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/BUILD.gn
[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller.cc
[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller.h
[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_cache_controller_unittest.cc
[add] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_provider.cc
[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/cc/output/context_provider.h
[modify] https://crrev.com/6714c23b526197220d8b9abdbd38b6d9c206d912/content/common/gpu/client/context_provider_command_buffer.cc

Project Member

Comment 27 by sheriffbot@chromium.org, Sep 28 2016

This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 28 by bugdroid1@chromium.org, Sep 29 2016

Labels: -merge-approved-54 merge-merged-2840
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c7bc434acf21c0330022455bb9f584c764991567

commit c7bc434acf21c0330022455bb9f584c764991567
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Sep 29 22:11:46 2016

Provide TaskRunner to ContextCacheController

Both ContextCacheController and the CommandBuffer/GpuControl need
access to a TaskRunner. CommandBuffer/GpuControl currently creates this
TaskRunner internally in most cases. This change moves TaskRunner
creation to the ContextProvider, allowing the same TaskRunner to be
passed to both objects.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2286873003
Cr-Commit-Position: refs/heads/master@{#419553}
(cherry picked from commit d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e)

BUG= 624630 

Review URL: https://codereview.chromium.org/2376123005 .

Cr-Commit-Position: refs/branch-heads/2840@{#588}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/android_webview/browser/aw_render_thread_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/raster/raster_buffer_provider_perftest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_benchmark.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/yuv_readback_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/content/common/gpu/client/context_provider_command_buffer.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/command_buffer_proxy_impl.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/gpu_in_process_context_tests.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/demo/bitmap_uploader.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/ui/compositor/test/in_process_context_provider.cc

Project Member

Comment 29 by bugdroid1@chromium.org, Sep 29 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/afec5ef67b207063bfbff5a5768b95b327393026

commit afec5ef67b207063bfbff5a5768b95b327393026
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Sep 29 22:17:16 2016

Idle cleanup for worker context

Currently, Skia flushes unused items out of its caches after ~1 second
of non-use (50 flushes). This works fine while Skia is in-use, but when
a worker context goes idle we stop calling into Skia altogether. This
means that Skia will never flush out unused cache items from the last
piece of work it did. This can lead to some rather large temporaries
being kept around (~20mb).

This change adds an idle cleanup process which flushes Skia's caches
and cleans up worker context resources after a worker context is idle
for 1 second.

BUG= 624630 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg

Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb
Review-Url: https://codereview.chromium.org/2353033003
Cr-Original-Commit-Position: refs/heads/master@{#420496}
Cr-Commit-Position: refs/heads/master@{#421092}
(cherry picked from commit 6714c23b526197220d8b9abdbd38b6d9c206d912)

Review URL: https://codereview.chromium.org/2382063002 .

Cr-Commit-Position: refs/branch-heads/2840@{#590}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/BUILD.gn
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.cc
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.h
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller_unittest.cc
[add] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.cc
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.h
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/content/common/gpu/client/context_provider_command_buffer.cc

Status: Fixed (was: Started)
My CL above addresses the memory concerns in this bug. I've forked the performance concerns to  crbug.com/651605  and  crbug.com/651607 , which are still open.

Closing this out.
Project Member

Comment 31 by bugdroid1@chromium.org, Oct 27 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c7bc434acf21c0330022455bb9f584c764991567

commit c7bc434acf21c0330022455bb9f584c764991567
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Sep 29 22:11:46 2016

Provide TaskRunner to ContextCacheController

Both ContextCacheController and the CommandBuffer/GpuControl need
access to a TaskRunner. CommandBuffer/GpuControl currently creates this
TaskRunner internally in most cases. This change moves TaskRunner
creation to the ContextProvider, allowing the same TaskRunner to be
passed to both objects.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel

Review-Url: https://codereview.chromium.org/2286873003
Cr-Commit-Position: refs/heads/master@{#419553}
(cherry picked from commit d989e6a0815a6f77d3a6fbab24afe9ff6abbf25e)

BUG= 624630 

Review URL: https://codereview.chromium.org/2376123005 .

Cr-Commit-Position: refs/branch-heads/2840@{#588}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/android_webview/browser/aw_render_thread_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/output/context_cache_controller_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/raster/raster_buffer_provider_perftest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/cc/test/test_in_process_context_provider.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_benchmark.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/gl_helper_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/components/display_compositor/yuv_readback_unittest.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/content/common/gpu/client/context_provider_command_buffer.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/client/gl_in_process_context.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/command_buffer/service/in_process_command_buffer.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/command_buffer_proxy_impl.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/gpu/ipc/client/gpu_in_process_context_tests.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/demo/bitmap_uploader.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/public/cpp/gles2_context.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.cc
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/services/ui/surfaces/surfaces_context_provider.h
[modify] https://crrev.com/c7bc434acf21c0330022455bb9f584c764991567/ui/compositor/test/in_process_context_provider.cc

Project Member

Comment 32 by bugdroid1@chromium.org, Oct 27 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/afec5ef67b207063bfbff5a5768b95b327393026

commit afec5ef67b207063bfbff5a5768b95b327393026
Author: Eric Karl <ericrk@chromium.org>
Date: Thu Sep 29 22:17:16 2016

Idle cleanup for worker context

Currently, Skia flushes unused items out of its caches after ~1 second
of non-use (50 flushes). This works fine while Skia is in-use, but when
a worker context goes idle we stop calling into Skia altogether. This
means that Skia will never flush out unused cache items from the last
piece of work it did. This can lead to some rather large temporaries
being kept around (~20mb).

This change adds an idle cleanup process which flushes Skia's caches
and cleans up worker context resources after a worker context is idle
for 1 second.

BUG= 624630 
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel;master.tryserver.blink:linux_precise_blink_dbg

Committed: https://crrev.com/051ae83bf29b52cefd82235ebfb90f203912afbb
Review-Url: https://codereview.chromium.org/2353033003
Cr-Original-Commit-Position: refs/heads/master@{#420496}
Cr-Commit-Position: refs/heads/master@{#421092}
(cherry picked from commit 6714c23b526197220d8b9abdbd38b6d9c206d912)

Review URL: https://codereview.chromium.org/2382063002 .

Cr-Commit-Position: refs/branch-heads/2840@{#590}
Cr-Branched-From: 1ae106dbab4bddd85132d5b75c670794311f4c57-refs/heads/master@{#414607}

[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/BUILD.gn
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.cc
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller.h
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_cache_controller_unittest.cc
[add] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.cc
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/cc/output/context_provider.h
[modify] https://crrev.com/afec5ef67b207063bfbff5a5768b95b327393026/content/common/gpu/client/context_provider_command_buffer.cc

Sign in to add a comment