Recent changes to mExtensions moved the initialization code from the
constructor to a separate function called load. Make sure to call
this function in the initExtensions function call.
Bug: 25615666
Change-Id: Ic016232c42afefd3b5bc3e4bd5c8428a11c454ad
Implement path parsing from string to skia path in native. The parsing
contains two main stages:
1) Parse string into a list of nodes that contains one operation (such
as move) and a vector of floats as params for that operation.
2) Interpret the operations defined in the nodes into SkPath operations,
and create a skia path
Also provided unit test for parsing a string path into a list of nodes,
and then to a skia path.
Change-Id: I0ce13df5e3bb90987dcdc80fe8b039af175ad2e2
When precache, PathTexture is added to PathCache, and it is released after drawn if we want to clean it.
But the PathCache LRU still holds the entry of the PathTexture object. When trim the cache in
the end of each frame, LRU finds that its mListener is not NULL and invoke the functor, however,
mListerer points to the released PathTexture object and is a dangling pointer, thus leads to crash.
Smart pointer don't help here since they only manage scopes, while PathTexture is also controled by
its cleanup field.
The fix is to also remove the LRU entry of PathTexture*, it will also release the texture object
and there won't be texture leaks.
Change-Id: Iaa0621df5dc71532e9e75b38ad94384353930b95
Partial Canvas save semantics (clip or matrix persisting after restore)
are currently emulated in the native canvas wrapper (SkiaCanvas.cpp).
Persistent clips (save w/ MATRIX_SAVE_FLAG only) in particular are
emulated using the SkCanvas clip stack. There are two problems with
the current implementation:
1) The canvas save count is used to identify the clip stack topmost
frame, on the assumption that it is the same as the actual clip stack
save count. But with the introduction of lazy SkCanvas saves in Skia,
the two values can diverge: the clip stack save count only reflects
*committed* saves, while the canvas save count includes both committed
and pending saves. This means that we can no longer compare canvas and
clip stack save counts directly.
While we're looking at addressing the save count discrepancy in Skia
proper, we can also refactor the partial save emulation to no longer
rely on the two values being synchronized: instead of using the canvas
save count to locate the top clip stack frame, simply use the clip
stack save count for the same purpose - getClipStack()->getSaveCount()
always points to the correct top clip stack frame.
With this patch:
* we use SkCanvas::getSaveCount() to track *canvas* save frames which
require persistent matrix/clip handling (mSaveRecStack)
* we use SkClipStack::getSaveCount() to extract the clips from the
top clip stack frame
Also, since we're no longer mixing/comparing the two save counts, we
don't have to decrement the canvas value anymore (to make it zero-based
like its clip stack counterpart).
2) When iterating over clip stack elements, we currently start at
kTopIterStart and advance using next(). This is incorrect as next()
moves up the stack, so we only iterate over the topmost element =>
if there are multiple (non-consolidated) clip elements in the top
frame, we only get to see one.
We need to iterate using prev() instead.
Change-Id: Ic2d8cad684018925e749b9172fbf7c6202d9fb62
