Treat opacity value close enough to 1.f as opaque |
|||
Issue descriptionWe use render pass to apply opacity. When the opacity is close enough to 1.f we could consider that opaque. This change should happen both in viz surface aggregator as well as cc should create render surface.
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f5d1e5dd562fffba3d6a26784217efc872a70b57 commit f5d1e5dd562fffba3d6a26784217efc872a70b57 Author: Weiliang Chen <weiliangc@chromium.org> Date: Mon Apr 16 21:13:45 2018 viz: Use Epsilon Value For Surface Aggregator Opaque Determination Surface Aggregator uses render surface to apply opacity. This CL uses an epsilon value to determine when opacity is close enough to 1.f to be considered opaque. R=enne Bug: 831779 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel Change-Id: Ic5f11429e4679c0990a9e441358701b8e3b5c7d2 Reviewed-on: https://chromium-review.googlesource.com/1008129 Reviewed-by: enne <enne@chromium.org> Commit-Queue: weiliangc <weiliangc@chromium.org> Cr-Commit-Position: refs/heads/master@{#551115} [modify] https://crrev.com/f5d1e5dd562fffba3d6a26784217efc872a70b57/components/viz/service/display/surface_aggregator.cc [modify] https://crrev.com/f5d1e5dd562fffba3d6a26784217efc872a70b57/components/viz/service/display/surface_aggregator_unittest.cc
,
May 30 2018
My plan is to work backwards from surface aggregator, so my next step is to look at effect tree and when they decide to have a render surface. Some of the code is ending up in PropertyTreeBuilder. Since has_render_surface is going to (or is?) being set when generated in Blink, would make sense to hand over to paint team afterwards. Thus cc'ing chrishtr@ and pdr@.
,
May 30 2018
Another possibility is to wait for https://bugs.chromium.org/p/chromium/issues/detail?id=501596 to be fixed, then we (probably) won't need the epsilon check at all. |
|||
►
Sign in to add a comment |
|||
Comment 1 by bugdroid1@chromium.org
, Apr 16 2018