|
|
Descriptioncc::ResourcePool - Re-use larger resources for smaller requests
Allows cc::ResourcePool to re-use larger resources to fulfill a smaller
request. This avoids expensive allocations, and is especially useful in
cases where layer sizes are changing due to animation.
Also extends the timeout for resource expiration from 1s to 5s, which
will also cut down on resource allocations.
CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel
Review-Url: https://codereview.chromium.org/2726263003
Cr-Original-Commit-Position: refs/heads/master@{#456202}
Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39e96c37a59f33
Review-Url: https://codereview.chromium.org/2726263003
Cr-Commit-Position: refs/heads/master@{#470023}
Committed: https://chromium.googlesource.com/chromium/src/+/0fc488920dd2915f5596dda347681e0571bb56dc
Patch Set 1 #Patch Set 2 : build fix #
Total comments: 3
Patch Set 3 : Base re-use threshold on pixel area, not individual dimensions. #
Total comments: 4
Patch Set 4 : improve unit tests #Patch Set 5 : Fix one copy issues #Patch Set 6 : cc::ResourcePool - Re-use larger resources for smaller requests #Patch Set 7 : rebase #
Total comments: 10
Patch Set 8 : rebase #Patch Set 9 : feedback #Patch Set 10 : fix compile #
Messages
Total messages: 89 (57 generated)
Description was changed from ========== Don't allocate a new resource if a larger one (within 2x) is available ========== to ========== Don't allocate a new resource if a larger one (within 2x) is available CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel ==========
Description was changed from ========== Don't allocate a new resource if a larger one (within 2x) is available CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel ========== to ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel ==========
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
ericrk@chromium.org changed reviewers: + enne@chromium.org
Let me know if this makes sense. Returning larger resources seems to work fine (we seem to track the actual size correctly). https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... File cc/resources/resource_pool.cc (right): https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... cc/resources/resource_pool.cc:50: base::TimeDelta::FromSeconds(5); Any number here is just a heuristic. 1 seemed to be too short, leading to a lot of allocation and freeing. Trying 5. Eventually we can switch to using GPU discardable and just unlocking rather than deleting, which should give us better behavior.
https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... File cc/resources/resource_pool.cc (right): https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... cc/resources/resource_pool.cc:30: const float kReuseScaleThreshold = 2.0f; driveby constant suggestion of something <= sqrt(2) so we waste up to <= 2x mem not up to 4x mem
lgtm % danakj's suggestion
Patchset #3 (id:40001) has been deleted
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... File cc/resources/resource_pool.cc (right): https://codereview.chromium.org/2726263003/diff/20001/cc/resources/resource_p... cc/resources/resource_pool.cc:30: const float kReuseScaleThreshold = 2.0f; On 2017/03/10 at 16:32:12, danakj wrote: > driveby constant suggestion of something <= sqrt(2) so we waste up to <= 2x mem not up to 4x mem I like limiting to 2x memory, but decided to go with a comparison of the areas of the requested vs actual resources. This allows for more re-use than per-dimension comparisons, while still limiting to 2x memory usage.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
danakj@chromium.org changed reviewers: + danakj@chromium.org
https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... File cc/resources/resource_pool.cc (right): https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... cc/resources/resource_pool.cc:40: float actual_area = actual_size.GetArea(); This will crash if it overflows (GetArea uses safe math). But sizes here can't be a problem for that right? https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... File cc/resources/resource_pool_unittest.cc (right): https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... cc/resources/resource_pool_unittest.cc:334: EXPECT_EQ(nullptr, resource_pool_->ReuseResource(gfx::Size(45, 99), format, Can you test the boundary cases a bit more to establish them in the test? 1/2 size width and height for example.
Patchset #4 (id:80001) has been deleted
Patchset #4 (id:100001) has been deleted
Patchset #4 (id:120001) has been deleted
https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... File cc/resources/resource_pool.cc (right): https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... cc/resources/resource_pool.cc:40: float actual_area = actual_size.GetArea(); On 2017/03/10 at 18:55:40, danakj wrote: > This will crash if it overflows (GetArea uses safe math). But sizes here can't be a problem for that right? I'm assuming that this can't be a problem - the sizes in use are all tile sizes, capped at max_texture_size. Added a comment. https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... File cc/resources/resource_pool_unittest.cc (right): https://codereview.chromium.org/2726263003/diff/60001/cc/resources/resource_p... cc/resources/resource_pool_unittest.cc:334: EXPECT_EQ(nullptr, resource_pool_->ReuseResource(gfx::Size(45, 99), format, On 2017/03/10 at 18:55:40, danakj wrote: > Can you test the boundary cases a bit more to establish them in the test? 1/2 size width and height for example. Done.
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Thanks! LGTM
The CQ bit was unchecked by ericrk@chromium.org
The CQ bit was checked by ericrk@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from enne@chromium.org Link to the patchset: https://codereview.chromium.org/2726263003/#ps140001 (title: "improve unit tests")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 140001, "attempt_start_ts": 1489184794617170, "parent_rev": "985672135b21e4512693ab3bbf0a9bdd5b362583", "commit_rev": "830cb220146684c38b9aa4da3f39e96c37a59f33"}
Message was sent while issue was closed.
Description was changed from ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel ========== to ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726263003 Cr-Commit-Position: refs/heads/master@{#456202} Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39... ==========
Message was sent while issue was closed.
Committed patchset #4 (id:140001) as https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39...
Message was sent while issue was closed.
A revert of this CL (patchset #4 id:140001) has been created in https://codereview.chromium.org/2744063002/ by wangxianzhu@chromium.org. The reason for reverting is: This seems to cause flakiness of several border-radius tests, e.g. https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType... Speculatively revert, to see if it's this CL..
Message was sent while issue was closed.
On 2017/03/11 02:16:41, Xianzhu wrote: > A revert of this CL (patchset #4 id:140001) has been created in > https://codereview.chromium.org/2744063002/ by mailto:wangxianzhu@chromium.org. > > The reason for reverting is: This seems to cause flakiness of several > border-radius tests, e.g. > https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType... > > Speculatively revert, to see if it's this CL.. Makes sense that it would be this CL - It looks like the renderer is fine with textures that are not exactly sized, except in the case of masks. These rely on exact-sizes. Will need to update the logic to either allow non-exact sizes for masks, or pass a flag indicating that certain content needs an exact allocation. Will look into this on Monday.
Message was sent while issue was closed.
Description was changed from ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726263003 Cr-Commit-Position: refs/heads/master@{#456202} Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39... ========== to ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726263003 Cr-Commit-Position: refs/heads/master@{#456202} Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39... ==========
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_trusty_blink_rel on master.tryserver.blink (JOB_FAILED, http://build.chromium.org/p/tryserver.blink/builders/linux_trusty_blink_rel/b...)
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
ericrk@chromium.org changed reviewers: + mkwst@chromium.org
+mkwst@ for content/shell/app/shell_main_delegate.cc enne@ or danakj@, can you take another quick look at this. Basically the same as last time, except that (a) I've landed a fix for the mask issue in a separate CL (crrev.com/2828353003) and (b) I've added a flag to disallow non-exact sizes during layout tests, as these introduce floating point noise and are non-deterministic.
https://codereview.chromium.org/2726263003/diff/200001/cc/base/switches.cc File cc/base/switches.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/base/switches.cc#ne... cc/base/switches.cc:121: // Intended only for use in layout tests to reduce noise. it would apply to any pixel tests right? say we had UI pixel tests in the future for instance.. https://codereview.chromium.org/2726263003/diff/200001/cc/output/renderer_set... File cc/output/renderer_settings.h (right): https://codereview.chromium.org/2726263003/diff/200001/cc/output/renderer_set... cc/output/renderer_settings.h:42: // resources in ResourcePool. Only used for layout tests, as the pixel tests? https://codereview.chromium.org/2726263003/diff/200001/cc/resources/resource_... File cc/resources/resource_pool_unittest.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/resources/resource_... cc/resources/resource_pool_unittest.cc:407: base::TimeDelta::FromMilliseconds(100), false); Add a test with true? https://codereview.chromium.org/2726263003/diff/200001/cc/trees/layer_tree_ho... File cc/trees/layer_tree_host_impl.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/trees/layer_tree_ho... cc/trees/layer_tree_host_impl.cc:2292: settings_.renderer_settings.disallow_non_exact_resource_reuse); Can you put it in LayerTreeSettings for here, and RendererSettings for GLRenderer. samans@ is currently splitting them apart and will have to do that. https://codereview.chromium.org/2726263003/diff/200001/ui/compositor/composit... File ui/compositor/compositor.cc (right): https://codereview.chromium.org/2726263003/diff/200001/ui/compositor/composit... ui/compositor/compositor.cc:193: settings.renderer_settings.disallow_non_exact_resource_reuse = This won't affect layout tests fwiw, but it's fine cuz it could apply for other types of pixel tests. But I don't see how the flag is getting to the renderer compositor.
lgtm. I don't have anything to add over danakj's comments.
//content/shell LGTM, but I generally prefer that we do relands of reverts in separate patches.
On 2017/05/05 at 09:36:03, mkwst wrote: > //content/shell LGTM, but I generally prefer that we do relands of reverts in separate patches. (I kind of prefer the opposite, because it keeps all the history and comments and changes in one place. <_<)
Patchset #8 (id:220001) has been deleted
Patchset #8 (id:240001) has been deleted
Patchset #9 (id:280001) has been deleted
ericrk@chromium.org changed reviewers: + ccameron@chromium.org
+ccameron@ for render_process_host_impl.cc change (just adding a flag to be passed through). https://codereview.chromium.org/2726263003/diff/200001/cc/base/switches.cc File cc/base/switches.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/base/switches.cc#ne... cc/base/switches.cc:121: // Intended only for use in layout tests to reduce noise. On 2017/05/04 21:48:37, danakj wrote: > it would apply to any pixel tests right? say we had UI pixel tests in the future > for instance.. Yup, anywhere where we aren't doing fuzzy comparison (the changes are *very* minor, so even a little bit of fuzz will allow them). https://codereview.chromium.org/2726263003/diff/200001/cc/output/renderer_set... File cc/output/renderer_settings.h (right): https://codereview.chromium.org/2726263003/diff/200001/cc/output/renderer_set... cc/output/renderer_settings.h:42: // resources in ResourcePool. Only used for layout tests, as the On 2017/05/04 21:48:37, danakj wrote: > pixel tests? Done. https://codereview.chromium.org/2726263003/diff/200001/cc/resources/resource_... File cc/resources/resource_pool_unittest.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/resources/resource_... cc/resources/resource_pool_unittest.cc:407: base::TimeDelta::FromMilliseconds(100), false); On 2017/05/04 21:48:37, danakj wrote: > Add a test with true? added. https://codereview.chromium.org/2726263003/diff/200001/cc/trees/layer_tree_ho... File cc/trees/layer_tree_host_impl.cc (right): https://codereview.chromium.org/2726263003/diff/200001/cc/trees/layer_tree_ho... cc/trees/layer_tree_host_impl.cc:2292: settings_.renderer_settings.disallow_non_exact_resource_reuse); On 2017/05/04 21:48:37, danakj wrote: > Can you put it in LayerTreeSettings for here, and RendererSettings for > GLRenderer. samans@ is currently splitting them apart and will have to do that. Done. https://codereview.chromium.org/2726263003/diff/200001/ui/compositor/composit... File ui/compositor/compositor.cc (right): https://codereview.chromium.org/2726263003/diff/200001/ui/compositor/composit... ui/compositor/compositor.cc:193: settings.renderer_settings.disallow_non_exact_resource_reuse = On 2017/05/04 21:48:37, danakj wrote: > This won't affect layout tests fwiw, but it's fine cuz it could apply for other > types of pixel tests. > > But I don't see how the flag is getting to the renderer compositor. Yup, missed the other half of this. Added it in.
The CQ bit was checked by ericrk@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)
On 2017/05/05 23:18:38, ericrk wrote: > +ccameron@ for render_process_host_impl.cc change (just adding a flag to be > passed through). content/browser/renderer_host lgtm As a drive-by, I like this patch, and I think it will help with performance. (and I have all sorts of bike-shed comments about how re-use strategies, but I won't add more noise by adding them -- this patch has the logic sequestered away in ResourcePool, so anyone who wants to mess with strategy is free to do so).
On 2017/05/06 05:43:13, ccameron wrote: > On 2017/05/05 23:18:38, ericrk wrote: > > +ccameron@ for render_process_host_impl.cc change (just adding a flag to be > > passed through). > > content/browser/renderer_host lgtm > > As a drive-by, I like this patch, and I think it will help with performance. > > (and I have all sorts of bike-shed comments about how re-use strategies, but I > won't add more noise by adding them -- this patch has the logic sequestered away > in ResourcePool, so anyone who wants to mess with strategy is free to do so). Nope, I lied! I won't restrain myself! We already do something similar for the IOSurfaces used by renderpasses. erikchen@ added code to do something similar in https://codereview.chromium.org/2245813002 The rule he used was to round up *all* allocations to the nearest 64 pixels. That scheme may end up being more reliable. But, please feel free to ignore this comment until some later date.
On 2017/05/06 05:59:17, ccameron wrote: > On 2017/05/06 05:43:13, ccameron wrote: > > On 2017/05/05 23:18:38, ericrk wrote: > > > +ccameron@ for render_process_host_impl.cc change (just adding a flag to be > > > passed through). > > > > content/browser/renderer_host lgtm > > > > As a drive-by, I like this patch, and I think it will help with performance. > > > > (and I have all sorts of bike-shed comments about how re-use strategies, but I > > won't add more noise by adding them -- this patch has the logic sequestered > away > > in ResourcePool, so anyone who wants to mess with strategy is free to do so). > > Nope, I lied! I won't restrain myself! We already do something similar for the > IOSurfaces used by renderpasses. > > erikchen@ added code to do something similar in > https://codereview.chromium.org/2245813002 > > The rule he used was to round up *all* allocations to the nearest 64 pixels. > That scheme may end up being more reliable. > > But, please feel free to ignore this comment until some later date. We already round up all tile allocations to the nearest 64 (or 32?) pixels, and this is meant to compliment that. The idea being that this is a bit more flexible than round-up behavior. This is specifically targeting cases where a div's size is animated, covering a large range of sizes: - Round-up may work, but in order to acheive similar re-use, we'd have to round up to {MAX_TILE_SIZE}/2, which can be quite large and would waste space in many cases. This patch opportunistically re-uses tiles *if* they happen to be available, without forcing large round-ups. - Round-up to smaller amounts can frequently miss cases where an animation crosses a rounding boundary (but not a 2x size boundary). We can't just move the round-to-64 tile logic here, as we also want to round tile-sizes (not just resource sizes), as this impacts parts of tile-rendering unrelated to resource size. Duplicating the logic here may be good, as it de-couples unrelated reasons for rounding, but we can do this in a follow-up.
The CQ bit was checked by ericrk@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from danakj@chromium.org, mkwst@chromium.org, enne@chromium.org, ccameron@chromium.org Link to the patchset: https://codereview.chromium.org/2726263003/#ps320001 (title: "fix compile")
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: android_compile_dbg on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_comp...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...) linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED, http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
The CQ bit was checked by ericrk@chromium.org
CQ is trying da patch. Follow status at: https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch. Bot data: {"patchset_id": 320001, "attempt_start_ts": 1494258731369150, "parent_rev": "9ce0013f7cb1f236cffbbae7bf43a6b7a8d09ef0", "commit_rev": "0fc488920dd2915f5596dda347681e0571bb56dc"}
Message was sent while issue was closed.
Description was changed from ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726263003 Cr-Commit-Position: refs/heads/master@{#456202} Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39... ========== to ========== cc::ResourcePool - Re-use larger resources for smaller requests Allows cc::ResourcePool to re-use larger resources to fulfill a smaller request. This avoids expensive allocations, and is especially useful in cases where layer sizes are changing due to animation. Also extends the timeout for resource expiration from 1s to 5s, which will also cut down on resource allocations. CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726263003 Cr-Original-Commit-Position: refs/heads/master@{#456202} Committed: https://chromium.googlesource.com/chromium/src/+/830cb220146684c38b9aa4da3f39... Review-Url: https://codereview.chromium.org/2726263003 Cr-Commit-Position: refs/heads/master@{#470023} Committed: https://chromium.googlesource.com/chromium/src/+/0fc488920dd2915f5596dda34768... ==========
Message was sent while issue was closed.
Committed patchset #10 (id:320001) as https://chromium.googlesource.com/chromium/src/+/0fc488920dd2915f5596dda34768... |