GLHelper scaling support for "patching" for performance |
||||||||
Issue descriptionFor the CopyOutputRequest execution use cases, GLHelper scaling should be able to support two methods of scaling just subsets of an entire original texture, by allowing the client to do either of the following: 1. Given the same source texture, but different output rects. 2. Given a smaller source texture (with overscan accounted for), and with an output rect having an upper-left corner of (0,0). This would allow for a huge performance boost to tab/desktop capture from the compositor, since the entire pipeline would be able to do far less work to generate a new frame that hasn't changed much from the prior frame. #1 is a matter of doing the right rect calculations throughout the multiple stages of the scaler impl. #2 is much more difficult, as this would require some of the scaler shader programs to be modified to operate on fractional coordinates (e.g., the bicubic scaler seems to assume whole-numbered source pixel coordinates, causing offset errors in the results).
,
Oct 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3 commit 43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3 Author: Yuri Wiitala <miu@chromium.org> Date: Mon Oct 23 22:18:02 2017 GLHelper: Split vertical-flip into the two separate things it means. This changes splits the GLHelper scaler's "vertical flip" mode into two separate things: 1) Whether the source texture content is vertically flipped (for the source rect math), and 2) Whether the scaler's output should be vertically flipped (to prevent the need to reverse the row order in a later readback operation). Bug: 760348 , 775740 Change-Id: Ieabfa0a6ec151ba47470677b45518604c7a80a26 Reviewed-on: https://chromium-review.googlesource.com/731766 Reviewed-by: Xiangjun Zhang <xjz@chromium.org> Reviewed-by: Fady Samuel <fsamuel@chromium.org> Commit-Queue: Yuri Wiitala <miu@chromium.org> Cr-Commit-Position: refs/heads/master@{#510938} [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper.h [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper_benchmark.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper_scaling.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper_scaling.h [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/common/gl_helper_unittest.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/components/viz/service/display/gl_renderer_copier.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/content/browser/media/capture/aura_window_capture_machine.cc [modify] https://crrev.com/43ebdaa507565a9abae4ce04b51e8fc7cd53c9f3/content/browser/renderer_host/delegated_frame_host.cc
,
Nov 8 2017
At this point, most of the work is done. However, one lingering issue should be addressed at some point: "some of the scaler shader programs to be modified to operate on fractional coordinates (e.g., the bicubic scaler seems to assume whole-numbered source pixel coordinates, causing offset errors in the results)." Since what was immediately needed is done, and the rest is lower priority, I'm downgrading the priority of this bug.
,
Feb 1 2018
,
Feb 1 2018
,
Feb 7 2018
,
Feb 7 2018
,
Nov 19
This was addressed in the new viz::GLScaler replacement.
,
Nov 19
*** UI Mass Triage *** |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by bugdroid1@chromium.org
, Oct 19 2017