Commit 4188df86 authored by danakj's avatar danakj Committed by Commit Bot

Avoid quickReject() when rastering a cc::DrawingDisplayItem.

The Rtree should already have avoided any items which don't intersect
with what we want to raster.

There may be scenarios where rejecting from the cull rect produces
slightly better results because of rounding while constructing the
visual rect, but these are extreme corner cases along tile boundaries
and should be rare, and not worth the extra overhead for the common
case, as demonstrated by the perf results.

R=wkorman@chromium.org

Bug: 671433
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I1556d618fa2d276525787fb903bdfa2d5aba653d
Reviewed-on: https://chromium-review.googlesource.com/506519
Commit-Queue: danakj <danakj@chromium.org>
Reviewed-by: default avatarKhushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#474014}
parent 6926aab4
...@@ -98,9 +98,6 @@ NOINLINE DISABLE_CFI_PERF void RasterItem(const DisplayItem& base_item, ...@@ -98,9 +98,6 @@ NOINLINE DISABLE_CFI_PERF void RasterItem(const DisplayItem& base_item,
break; break;
case DisplayItem::DRAWING: { case DisplayItem::DRAWING: {
const auto& item = static_cast<const DrawingDisplayItem&>(base_item); const auto& item = static_cast<const DrawingDisplayItem&>(base_item);
if (canvas->quickReject(item.bounds))
break;
// TODO(enne): Maybe the PaintRecord itself could know whether this // TODO(enne): Maybe the PaintRecord itself could know whether this
// was needed? It's not clear whether these save/restore semantics // was needed? It's not clear whether these save/restore semantics
// that SkPicture handles during playback are things that should be // that SkPicture handles during playback are things that should be
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment