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
Status: Accepted
Owner:
Cc:
Area: API
Priority: Medium
Type: Defect



Sign in to add a comment
make SkCanvas::replayClips() private or remove it
Project Member Reported by reed@google.com, Sep 4 2014 Back to list
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.
 
Project Member Comment 1 by hcm@google.com, Oct 14 2014
Labels: Area-API
Project Member Comment 2 by hcm@google.com, Dec 7 2015
Labels: Hotlist-Fixit
Project Member Comment 3 by caryclark@google.com, Jan 5 2016
Cc: -djsollen@google.com
Owner: djsollen@google.com
Can you comment on fixing #2?
Project Member Comment 4 by djsollen@google.com, Jan 7 2016
Owner: reed@google.com
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.
Sign in to add a comment