DescriptionRevert of 4x allocation in PipeController is probably overkill. (https://codereview.chromium.org/267863002/)
Reason for revert:
~29% perf regression in Chrome's Animation_balls-canvas bench on Macs. Going to cut up and reland in pieces.
https://code.google.com/p/chromium/issues/detail?id=372671
Original issue's description:
> 4x allocation in PipeController is probably overkill.
>
> When verylargebitmap GM runs in cross-process pipe mode, we're
> requestBlock()ing ~200M to carry the bitmaps. The current
> implementation ends up allocating ~800M, which is a bit wasteful.
>
> SkGPipeWrite already rounds up to 16K, so just rely on that.
>
> This change exposed several bugs in pipe:
> - we don't reserve enough space in drawVertices
> - we don't reserve enough space for factory names in cross-process mode
> - we don't quite have the right check in needOpBytes to see if we needed to send off the current block and allocate a new one
>
> SETUP_NOTIFY and generally calling doNotify() more often than necessary made things hard to debug and understand. Now the pipe always waits to send off its current block until it needs more space than that block can provide, or it's the final block. We can put these back if we need the proactive flushing, but it seems not necessary?
>
> Removed an assert in DeferredCanvasTest, which is somtimes 2 (Debug), sometimes 3 (Release). It seemed like the other asserts were more essential, and this one was more of a white-box assertion. Still sound if we remove it?
>
> BUG=skia:2478
>
> Committed: http://code.google.com/p/skia/source/detail?r=14613
TBR=scroggo@google.com,reed@google.com,junov@chromium.org,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:2478
Patch Set 1 #
Created: 6 years, 7 months ago
(Patch set is too large to download)
Messages
Total messages: 4 (0 generated)
|