Implement a finch experiment for not compositing small scrollers |
|||
Issue descriptionVersion: 58+ OS: All Eng owner: yigu Having a finch experiment in place will provide us with data for evaluating the GPU memory usage for not compositing small scrollers. Finch/experimentation: On android devices, the scrollbar of a scroller will appear if the scroller is not composited. This experiment therefore may reveal the scrollbars of small scrollers to users. This experiment MAY affect perf related metrics because not compositing small scrollers means that the scroll is handled by main thread. According to the previous experiments regarding size of scroller on page load and on scroll, we come up with a threshold, with which we composite ~60% less scrollers (to save memory) and at most 10% scroll may be slowed down. It's at most 10% because: 1. Today we are not compositing some of the small scrollers if they cannot be composited(e.g. has border radius). Even if some small scrollers get composited, we may still need to scroll them on main thread. Therefore the experiment doesn't affect those scrollers mentioned above because they have been slowly scrolled already; 2. with this experiment we still composite small scrollers if they have to be composited due to correctness so they will be fast scrolled as usual.
,
Jun 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3abfb995607fad374795c7abd737c4d012e7d7b0 commit 3abfb995607fad374795c7abd737c4d012e7d7b0 Author: yigu <yigu@chromium.org> Date: Wed Jun 07 20:37:19 2017 Add a feature for not compositing small scrollers We find that more than ~60% scrollers(scrollbars) are smaller than certain size and only 10% of them gets scrolled by users. As a result, we are thinking of not compositing the small scrollers to save GPU memory. The experiment is to investigate how much memory gains we could get without compositing them. Having a finch experiment in place will provide us with data for evaluating the GPU memory usage for not compositing small scrollers. This patch is to add a relative feature. BUG= 728267 Review-Url: https://codereview.chromium.org/2912403003 Cr-Commit-Position: refs/heads/master@{#477753} [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/child/runtime_features.cc [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/public/common/content_features.cc [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/public/common/content_features.h [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5 [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/public/platform/WebRuntimeFeatures.h
,
Jun 7 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3abfb995607fad374795c7abd737c4d012e7d7b0 commit 3abfb995607fad374795c7abd737c4d012e7d7b0 Author: yigu <yigu@chromium.org> Date: Wed Jun 07 20:37:19 2017 Add a feature for not compositing small scrollers We find that more than ~60% scrollers(scrollbars) are smaller than certain size and only 10% of them gets scrolled by users. As a result, we are thinking of not compositing the small scrollers to save GPU memory. The experiment is to investigate how much memory gains we could get without compositing them. Having a finch experiment in place will provide us with data for evaluating the GPU memory usage for not compositing small scrollers. This patch is to add a relative feature. BUG= 728267 Review-Url: https://codereview.chromium.org/2912403003 Cr-Commit-Position: refs/heads/master@{#477753} [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/child/runtime_features.cc [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/public/common/content_features.cc [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/content/public/common/content_features.h [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5 [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/Source/platform/exported/WebRuntimeFeatures.cpp [modify] https://crrev.com/3abfb995607fad374795c7abd737c4d012e7d7b0/third_party/WebKit/public/platform/WebRuntimeFeatures.h
,
Sep 12 2017
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues. We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate. For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit For any questions, please contact owencm, sshruthi, larforge
,
Nov 23 2017
|
|||
►
Sign in to add a comment |
|||
Comment 1 by yigu@chromium.org
, Jun 7 2017