Introduced PathData in Java, which is effectively a thin layer around the
native instance. PathData holds the verbs and points which is being used
in path morphing/interpolation. The verbs and points can be interpreted
into skia path commands, which is now done in native and therefore saves
a handful of JNI calls during path creation.
Removed the old PathDataNode mechanism and changed the PathEvaluator
to use PathData instead.
Also added tests and a microbench. Also ran CTS tests for VectorDrawable
and AnimatedVectorDrawable, and passed all of the existing tests.
Change-Id: Ia166f5172ff031fe18b154327967f911a62caec1
Also adds logic to clip temporary layers to viewport both for
efficiency and to allow large ones (such as the fallback case) to fit
in max texture size.
Change-Id: Iee51495220f5ca1dc7e6f5fd3615db2e896efd74
Now passes alphas and light radius, and correctly transforms light
center for layers.
Also fixes begin-frame/layer clears to be damage rect aware.
Change-Id: I3b1415cd7bf1518c510145ebebdb745f494a2542
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
