Re-raster during scale animations for GPU raster can lead to poor performance |
||||
Issue descriptionEarly in Ganesh's lifetime, code was added to which caused Ganesh to re-raster scale animations every frame (vs software, which I believe rasters once at largest scale and interpolates). The goal was to keep content crisp, and the theory was the Ganesh could achieve good framerates while constantly re-rastering. See https://crrev.com/422233008. While this is true in many cases, there are some (pathalogical?) cases where this difference causes Ganesh to perform far worse than SW (as Ganesh has to raster significantly more content). For an example, consider https://jsfiddle.net/93ggr9ho/13/embedded/result/. This page fakes a dynamic blur by blurring an image at 4 different blur radii, then transitioning between the blur levels using opacity. In the SW case, all 4 images are rasterized once, and then the images are just blended during compositing. In the GPU case, becuase we re-raster at each scale, we end up re rastering two visible scales each frame. This means we need to push 3 screens worth of pixels each frame (including compositing). This leads to poor performance in Ganesh. There may be other factors making this problematic for Ganesh as well (I'll keep investigating). The question here is, given that SW raster is the standard on desktop, do we really need to go for higher-quality with Ganesh (at the cost of performance)? Also, can we get some insight into why this was initially done? Were there Android mobile UIs that this benefited? It's already somewhat special-cased, as text disables this path for GPU (making it behave like SW). If we do want to keep this quality optimization in some cases, we might want to do things a bit more conservatively (re-raster at 2x scales, like pinch-zoom?) Anyway, wanted to get thoughts on the best way to address this, as it seems like the current rule is a bit too general.
,
Jun 29 2016
Interesting. When switching to threaded GPU rasterization I removed other such differences between Software and Ganesh. This is something I must have missed, but matching Software seems correct given current goals of running Ganesh on all content.
,
Jul 20 2016
,
Jul 21 2016
Eric, just fix this then? Also, given the recent change to re-raster even in the software path on scale change, is this bug obsolete already?
,
Jul 21 2016
Not obsolete, since the recent change doesn't affect css animations.
,
Jul 21 2016
Sounds like it makes sense to update things so GPU matches SW in this case? Given that they both are rasterizing a layer and producing tiles on the GPU, I'd expect the size concerns to be the same for each? If this makes sense I'll send out a CL.
,
Jul 21 2016
Yeah, having GPU match SW in that case makes sense to me.
,
Sep 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/0230527ec6f04133dcbeb488474c13e895157ea5 commit 0230527ec6f04133dcbeb488474c13e895157ea5 Author: ericrk <ericrk@chromium.org> Date: Thu Sep 01 17:18:06 2016 Don't adjust raster scale differently for SW/GPU When GPU raster was initially enabled, we caused GPU raster to adjust raster scale during animations, re-rastering each animation frame at its native resolution. While this is theoretically higher quality, this causes GPU raster to do significantly more work than SW in these cases. As downscaling has produced acceptable quality for SW, this change causes GPU to match SW's behavior, improving GPU raster performance in these cases. R=ajuma BUG= 624595 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_precise_blink_rel Review-Url: https://codereview.chromium.org/2289123005 Cr-Commit-Position: refs/heads/master@{#415984} [modify] https://crrev.com/0230527ec6f04133dcbeb488474c13e895157ea5/cc/layers/picture_layer_impl.cc [modify] https://crrev.com/0230527ec6f04133dcbeb488474c13e895157ea5/cc/layers/picture_layer_impl.h [modify] https://crrev.com/0230527ec6f04133dcbeb488474c13e895157ea5/cc/layers/picture_layer_impl_unittest.cc
,
Sep 1 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by ajuma@chromium.org
, Jun 29 2016