OSDN Git Service

Fix bug in PathMeasure with trimmed paths
authorChet Haase <chet@google.com>
Wed, 15 Jan 2014 19:45:25 +0000 (11:45 -0800)
committerChet Haase <chet@google.com>
Wed, 15 Jan 2014 20:12:20 +0000 (12:12 -0800)
Logic in the hardware renderer optimizes path rendering for simple
paths that consist of only rectangles. Any operation on the path that
adds any other primitive sets the simplicity flag to false appropriately.
PathMeasure.getSegment(), however, avoids those code paths and never sets
the mIsSimple flag at all, so it returns its original value (true, if the
path was simply constructed with no operations before being used in the
getSegment() call).

The fix is to avoid the optimization for paths used in getSegment(), since
it's not clear what operations will end up in the path and it's likely not
going to be just simple rectangles in any case.

Issue #12533902 PathMeasure.getSegment is broken

Change-Id: I71e77207e4d5c649c326557d33eba31e9b0fd45e

graphics/java/android/graphics/PathMeasure.java

index 7062824..dba1943 100644 (file)
@@ -113,9 +113,15 @@ public class PathMeasure {
      * segment(s). If the segment is zero-length, return false, else return
      * true. startD and stopD are pinned to legal values (0..getLength()).
      * If startD <= stopD then return false (and leave dst untouched).
-     * Begin the segment with a moveTo if startWithMoveTo is true
+     * Begin the segment with a moveTo if startWithMoveTo is true.
+     *
+     * <p>On {@link android.os.Build.VERSION_CODES#KITKAT} and earlier
+     * releases, the resulting path may not display on a hardware-accelerated
+     * Canvas. A simple workaround is to add a single operation to this path,
+     * such as <code>dst.rLineTo(0, 0)</code>.</p>
      */
     public boolean getSegment(float startD, float stopD, Path dst, boolean startWithMoveTo) {
+        dst.isSimplePath = false;
         return native_getSegment(native_instance, startD, stopD, dst.ni(), startWithMoveTo);
     }