Skia 101 Supporting tagline
Introduction
Skia is organized around the Canvas object. It is the host for the “draw” calls: drawRect, drawPath, drawText, etc. Each of these has two components: the primitive being drawn (SkRect, SkPath, etc.) and color/style attributes (SkPaint).
canvas.drawRect(rect, paint);
The paint holds much of the state describing how the rectangle (in this case) is drawn: what color it is, if it is filled or stroked, how it should blend with what was previously drawn.
The canvas holds relatively little state. It points to the actual pixels being drawn (hosted by a Bitmap), and it maintains a stack of matrices and clips. Thus in the above call, the canvas’ current matrix may transform the coordinates of the rectangle (translation, rotation, skewing, perspective), and the canvas’ current clip may restrict where on the canvas the rectangle will be drawn, but all other stylistic attributes of the drawing are controlled by the paint.
Important Structures
##SkCanvas SkCanvas is the drawing context for Skia. It knows where to direct the drawing (i.e. where the screen of offscreen pixels are), and maintains a stack of matrices and clips. Note however, that unlike similar contexts in other APIs like postscript, cairo, or awt, Skia does not store any other drawing attributes in the context (e.g. color, pen size). Rather, these are specified explicitly in each draw call, via a SkPaint.
SkPaint
Anytime you draw something in Skia, and want to specify what color it is, or how it blends with the background, or what style or font to draw it in, you specify those attributes in a paint.
Unlike SkCanvas, paints do not maintain an internal stack of state (i.e. there is no save/restore on a paint). However, paints are relatively light-weight, so the client may create and maintain any number of paint objects, each setup for a particular use. Factoring all of these color and stylistic attribute out of the canvas state, and into (multiple) paint objects, allows canvas’ save/restore to be that much more efficient, as all they have to do is maintain the stack of matrix and clip settings.
GrContext
GrContext is the public API object you create for talking to the GPU. It manages the GPU context, and related caches for textures and fonts.
GrRenderTarget
GrRenderTarget represents a 2D buffer of pixels that can be rendered to.
A context’s render target is set by setRenderTarget(). Render targets are
created by a createTexture with the kRenderTarget_TextureFlag flag.
Additionally, GrContext provides methods for creating GrRenderTargets
that wrap externally created render targets.
GrPaint
The paint describes how color and coverage are computed at each pixel by GrContext draw
functions and the how color is blended with the destination pixel.
The paint allows installation of custom color and coverage stages. New types of stages are
created by subclassing GrEffect.
The primitive color computation starts with the color specified by setColor(). This color is the
input to the first color stage. Each color stage feeds its output to the next color stage. The
final color stage’s output color is input to the color filter specified by
setXfermodeColorFilter which produces the final source color, S.
Fractional pixel coverage follows a similar flow. The coverage is initially the value specified
by setCoverage(). This is input to the first coverage stage. Coverage stages are chained
together in the same manner as color stages. The output of the last stage is modulated by any
fractional coverage produced by anti-aliasing. This last step produces the final coverage, C.
setBlendFunc() specifies blending coefficients for S (described above) and D, the initial value
of the destination pixel, labeled Bs and Bd respectively. The final value of the destination
pixel is then D' = (1-C)*D + C*(Bd*D + Bs*S).
Note that the coverage is applied after the blend. This is why they are computed as distinct values.