New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 4 users

Issue metadata

Status: Fixed
Closed: Feb 2018
Area: API
NextAction: ----
Priority: Medium
Type: Defect

Sign in to add a comment

Issue 2913: make SkCanvas::replayClips() private or remove it

Reported by, Sep 4 2014 Project Member

Issue description

There seem to only be two callers:

1. SkCanvasStateUtils::CaptureCanvasState
2. SkiaCanvas in android framework

I think #1 can logically be eliminated, as the canvas is always raster (it came from the framework), and the framework doesn't have soft clips.

#2 is for Canvas::setBitmap, which tries to create a new native canvas for an existing java one, while keeping the current matrix and clip state.

One motivation to remove this is that it locks us into always having a clipstack in the canvas. Today only the gpu-backend actually uses this clipstack, and it would be nicer to not create one for raster or picture canvases.

Comment 1 by, Oct 14 2014

Project Member
Labels: Area-API

Comment 2 by, Dec 7 2015

Project Member
Labels: Hotlist-Fixit

Comment 3 by, Jan 5 2016

Project Member
Can you comment on fixing #2?

Comment 4 by, Jan 7 2016

Project Member
I don't see how to eliminate the requirement in #2 in the short term without affecting the SDK.  We could update the behavior to not perserve the matrix-clip state, but we'll need to get Android buy-in for that.  In the long term we should deprecate the Canvas::setBitmap call in Java to clean it up.

Comment 5 by, Feb 27 2018

Project Member
Status: Fixed (was: Accepted)
it has been removed

Sign in to add a comment