Add a flag slow-down-compositing to renderer so that we can evaluate the improvement of cache render surface. |
||||
Issue descriptionCurrently the improvement by caching render surface may not obvious because there are other factors involved during animation, such as rasterization. Therefore by caching the render surface alone we may not see huge improvement in the animation smoothness. We might be able to evaluate this in another way: we add a flag slow-down-compositing to renderer, so that we can repeatedly draw render surface, to keep the same smoothness we can achieve in the animation. e.g. if without cache, we draw once render pass, we got animation frame rate 50 fps. If we using the cache, we draw twice render pass, if we still can get 50 fps, means by caching the render pass, we improvement efficiency to 2x. But we may not get 100% improvement in reality, so another example could be: without cache, we get 50 fps, with cache and repeat drawing twice, we get 40 fps. This might be equivalent to 40*2/50 = 1.6x in improvement.
,
Aug 8 2017
One possible solution is to add the flag to renderer settings (src/components/viz/common/display/renderer_settings.h), and access the flag in direct_renderer.cc, DirectRenderer::DrawRenderPassAndExecuteCopyRequests: for (int i = 0; i < repeat_count; ++i) DrawRenderPass(render_pass); Similar to slow_down_raster_scale_factor [2]. Add some cc owners for suggestions. [1] https://cs.chromium.org/chromium/src/cc/output/direct_renderer.cc?l=492&rcl=034f09fb84756039a913e27ceba7556ad8ffb891 [2] https://cs.chromium.org/chromium/src/cc/raster/raster_source.cc?l=162&rcl=ebe22580ea36ba92cf08d27d4137fa7a9bf39e3a
,
Aug 9 2017
+vmpstr@
,
Aug 9 2017
,
Aug 9 2017
Talking about slow_down_raster_scale_factor specifically, we had mixed success with using that. Specifically, we have the flag and it certainly works and we can specify it via --slow-down-raster-scale-factor. However, after the initial couple of weeks/months of testing, we stopped using the flag because we confirmed whatever it is we wanted to confirm with our features. Now it's a more-or-less dead flag and weird code complexity that we still maintain (and probably should remove it). Now we use something like rasterize and record microbenchmark that internally does repeated rasters to measure impact. So whereas I agree with you that this would successfully measure the caching impact, I think that it's better to do this as a one-off measurement, gather the numbers and publicize them. I would be somewhat opposed to adding a (permanent) flag for this. Again, the reason is that if you add the flag, and use it for the measurements, realistically after a week or a month it will become a dead flag. Or do you have other uses for this? As for the actual plan if you have this flag locally, it sounds like a good way to measure the impact. Specifically, draw once without cache = X fps draw once with cache = ~X fps draw N times without cache = Y fps draw N times with cache = Z fps where Z > Y. From Z and Y you can determine the improvement the cache provides. Does that sound reasonable?
,
Aug 9 2017
To clarify, if the cache improvements aren't a one-patch type of deal, then I'm ok with adding this, but having a bug to track removing this when our cache improvements are good. If we need long term metrics, it feels like an approach like rasterize and record benchmark would be more appropriate.
,
Aug 9 2017
Some background; We're looking for a good way to measure improvements for UI animations on ChromeOS (not specifically the use of render surface caching). Many animations run OK on faster devices but drop frames on slower machines. Most developers have access to fast machines like Samus (Chromebook Pixel 2015) but not to slower machines and we'd like to make it easier for them to ensure that animations are smooth across all ChromeOS devices. If an animation is already running at 60 fps on Samus than it becomes hard to measure improvements unless we have access to a slower machine or can artificially make compositing more expensive using something like the suggested slow-down-compositing flag.
,
Aug 9 2017
Yeah, enne@ has also mentioned that the slow down raster flag might be useful on things like ChromeOS. The whole plan sounds good to me, especially if it's useful for numerous reasons. My opposition is primarily due to the fact that I haven't felt the pain of trying to replicate a behavior of a slow chromeos device on a fast one. I would just caution to try and limit the code complexity in order to implement this, but I don't think that's contentious advice in general :)
,
Aug 9 2017
Yes, it would be great to keep the slow-down-raster flag too as the next step after turning on render surface caching when appropriate is to better synchronize raster to start/stop of animations. I agree that we should try hard to minimize the complexity that these flags add to the compositor.
,
Aug 9 2017
Thank you reveman@ and vmpstr@ to address this. Do you think viz::RendererSettings [1] is a good place to add this flag? And we access it in direct_renderer similar to the flag of show_overdraw_feedback [2]. [1] https://cs.chromium.org/chromium/src/components/viz/common/display/renderer_settings.h?l=15&rcl=2e72b474826fcc273d9ce3315c7eebb3f1a3804f [2] https://cs.chromium.org/chromium/src/cc/output/direct_renderer.cc?l=242&rcl=034f09fb84756039a913e27ceba7556ad8ffb891
,
Aug 9 2017
Sgtm. And maybe loop over DrawRenderPass call N times in DrawRenderPassAndExecuteCopyRequests?
,
Aug 10 2017
Uploaded a cl to: https://chromium-review.googlesource.com/609492
,
Aug 18 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4abd415249b454c1520f6ab9465564edcb3bb974 commit 4abd415249b454c1520f6ab9465564edcb3bb974 Author: wutao <wutao@chromium.org> Date: Fri Aug 18 23:14:42 2017 Add flag to slow down compositing to evaluate render surface caching. We are looking for a good way to measure improvements for UI animations on ChromeOS when we caching render surface. Many animations run OK on faster devices but drop frames on slower machines. Most developers have access to fast machines but not to slower machines and we would like to make it easier for them to ensure that animations are smooth across all ChromeOS devices. If an animation is already running at 60 fps on fast devices then it becomes hard to measure improvements unless we have access to a slower machine. Here we can artificially make compositing more expensive by adding a slow-down-compositing flag to renderer. Repeated draw to simulate a slower device for the evaluation of performance improvements in UI effects by using cache of render surface. Bug: 753232 Test: test new flag --slow-down-raster-scale-factor=different values. Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel Change-Id: I4483cdb848658e0644529a7d932d28ab3749c644 Reviewed-on: https://chromium-review.googlesource.com/609492 Reviewed-by: Robert Kroeger <rjkroege@chromium.org> Reviewed-by: Nico Weber <thakis@chromium.org> Reviewed-by: Oliver Chang <ochang@chromium.org> Reviewed-by: David Reveman <reveman@chromium.org> Reviewed-by: Vladimir Levin <vmpstr@chromium.org> Commit-Queue: Tao Wu <wutao@chromium.org> Cr-Commit-Position: refs/heads/master@{#495734} [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/cc/output/direct_renderer.cc [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/components/viz/common/display/renderer_settings.h [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/components/viz/host/renderer_settings_creation.cc [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/services/viz/privileged/interfaces/compositing/renderer_settings.mojom [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/services/viz/privileged/interfaces/compositing/renderer_settings_struct_traits.cc [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/services/viz/privileged/interfaces/compositing/renderer_settings_struct_traits.h [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/ui/base/ui_base_switches.cc [modify] https://crrev.com/4abd415249b454c1520f6ab9465564edcb3bb974/ui/base/ui_base_switches.h
,
Aug 29 2017
|
||||
►
Sign in to add a comment |
||||
Comment 1 by wutao@chromium.org
, Aug 8 2017