Bump skia to milestone 147

[ramezgerges]

Description of Change

Update the Skia graphics library from milestone 133 to milestone 147, a 14-milestone jump covering upstream changes from Chrome 133 through Chrome 147.

Bugs Fixed

• Fixes #

Changes

• SKPath is now immutable — construction methods moved to SKPathBuilder
• Added SKColorType.R16Unorm
• Updated versions to 3.147.0
• Regenerated bindings and updated all tests
• Added tests for SKFont.GetTextPath with per-glyph positions
• Removed ICC profile fields from encoder option structs
• Fixed WASM build for .a.wasm extension
• Fixed macOS/iOS Xcode projects (C++20, removed iOS -all_load)
• Updated update-skia skill with reusable learnings

Behavioral Changes

Change	Migration
SKPath mutation methods removed	Use SKPathBuilder + Detach()
SKPath.Rewind() removed	Use SKPathBuilder.Reset()
SKPaint.GetFillPath dst parameter	Change to SKPathBuilder
SKPathMeasure.GetSegment dst parameter	Change to SKPathBuilder
SKColorType enum values shifted	Use named members
Encoder option ICC profile fields removed	Remove from constructors

Required skia PR

mono/skia#184

PR Checklist

• Has tests (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Merged related skia PRs
• Changes adhere to coding standard
• Updated documentation

[github-actions]

📦 Try the packages from this PR

Warning

Do not run these scripts without first reviewing the code in this PR.

Step 1 — Download the packages

bash / macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.sh | bash -s -- 3702

PowerShell / Windows:

iex "& { $(irm https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.ps1) } 3702"

Step 2 — Add the local NuGet source

dotnet nuget add source ~/.skiasharp/hives/pr-3702/packages --name skiasharp-pr-3702

More options

Option	Description
--successful-only / -SuccessfulOnly	Only use successful builds
--force / -Force	Overwrite previously downloaded packages
--list / -List	List available artifacts without downloading
--build-id ID / -BuildId ID	Download from a specific build

Or download manually from Azure Pipelines — look for the nuget artifact on the build for this PR.

Remove the source when you're done:

dotnet nuget remove source skiasharp-pr-3702

[mattleibow]

ABI Breaking Changes in SKPath

This PR removes ~30 public mutation methods from SKPath (MoveTo, LineTo, AddRect, etc.) without deprecation, and changes GetFillPath/GetSegment signatures from SKPath dst to SKPathBuilder dst. This will break every downstream consumer that builds paths.

SkiaSharp's stated policy is "deprecate, don't remove." We should provide a migration runway.

Background

Upstream Skia made SkPath geometry-immutable starting at m143 (guarded by SK_HIDE_PATH_EDIT_METHODS), with the flag and all mutation code permanently removed in m145 (commit 98c01ea504 — "Remove dead code related to SkPathRef"). The internal backing store changed from SkPathRef (COW, mutable) to SkPathData (single immutable allocation). There is no going back upstream.

However, SkPath retains operator=, reset(), setFillType(), and swap() in m147 — it's a value type that can be replaced wholesale. The C API already exploits this pattern: sk_path_transform does makeTransform() → *AsPath(cpath) = std::move(result).

Migration Timeline

Version key:

• vPR — this PR / the major release containing this Skia bump (includes docs update)
• vNext — the next major release after vPR (compile errors, ABI still present)
• vFuture — the major release after vNext (optional: full removal of compat shims)

Release	Action	Consumer impact
vPR	Add SKPathBuilder + restore [Obsolete] mutation methods on SKPath + docs/migration guide	⚠️ Warnings only, zero source breaks
vNext	Change to [Obsolete("...", error: true)] — ABI still exists and works for already-compiled apps, but recompilation produces errors	❌ Compile errors with clear migration message; existing binaries unaffected
vFuture (optional)	Remove compat methods entirely, delete shim code	Clean immutable SKPath

Proposal: Two Options (+ last-resort alternative)

All options restore the same [Obsolete] C# API surface on SKPath. They differ only in where the builder-based mutation shim lives. Benchmarking is needed to determine which performs best in practice.

Option A: C# Shims (simplest, highest overhead)

Add 1 new C API function:

void sk_path_set_from_builder(sk_path_t* dst, sk_pathbuilder_t* src) {
    *AsPath(dst) = AsPathBuilder(src)->detach();
}

All mutation methods are pure C# wrappers:

[Obsolete("Use SKPathBuilder. SKPath will be immutable in a future version of SkiaSharp.")]
public void LineTo(float x, float y)
{
    using var b = new SKPathBuilder(this);
    b.LineTo(x, y);
    SkiaApi.sk_path_set_from_builder(Handle, b.Handle);
}

Pros:

• Minimal native changes (1 function, 2 lines of C++)
• No new opaque types, no new C++ classes, no build file changes
• Compat code lives entirely in C# — trivially removable in vFuture
• Easiest to review and maintain

Cons:

• Highest per-call overhead: managed SKPathBuilder allocation + 3 P/Invoke round-trips per mutation (new_from_path, mutation, set_from_builder)
• O(N) per call, O(N²) for incremental path building of N segments

Option B: C API Shims (moderate complexity, lower overhead)

Restore the old sk_path_* mutation functions directly in sk_path.cpp, using the same builder-detach-assign pattern that sk_path_transform already uses:

void sk_path_move_to(sk_path_t* cpath, float x, float y) {
    SkPathBuilder b(*AsPath(cpath));
    b.moveTo(x, y);
    *AsPath(cpath) = b.detach();
}

void sk_path_line_to(sk_path_t* cpath, float x, float y) {
    SkPathBuilder b(*AsPath(cpath));
    b.lineTo(x, y);
    *AsPath(cpath) = b.detach();
}
// ... ~30 functions

C# just calls through like the old API:

[Obsolete("Use SKPathBuilder. SKPath will be immutable in a future version of SkiaSharp.")]
public void LineTo(float x, float y) =>
    SkiaApi.sk_path_line_to(Handle, x, y);

Pros:

• No managed allocations per mutation — everything happens in a single native call
• 1 P/Invoke per mutation instead of 3
• No new types — uses existing sk_path_t*
• C# compat code is trivial one-liners (just like the old code)
• Same pattern as existing sk_path_transform

Cons:

• ~30 new functions in sk_path.cpp / sk_path.h (the old declarations come back)
• Still O(N) per call, O(N²) for incremental building (same fundamental cost)
• Mutation functions on sk_path_* blur the line between real SkPath API and compat shims
• Removing them in vFuture means another C API change

Option C: SkCompatPath with Lazy Batching (last resort — has critical issues)

⚠️ This option is documented for analysis only. It has a fundamental type-safety issue (see below) that makes it unsuitable unless significant additional infrastructure is added. Options A and B are the recommended paths.

Follow the SkCompatPaint pattern — create SkCompatPath : public SkPath in src/xamarin/ with an internal SkPathBuilder that batches mutations and only flushes on read:

class SkCompatPath : public SkPath {
    SkPathBuilder* fBuilder = nullptr;

    void ensureBuilder() {
        if (!fBuilder) fBuilder = new SkPathBuilder(*this);
    }

    void flush() {
        if (!fBuilder) return;
        SkPath::operator=(fBuilder->detach());
        delete fBuilder;
        fBuilder = nullptr;
    }

public:
    void lineTo(float x, float y) {
        ensureBuilder();
        fBuilder->lineTo(x, y);
    }

    // Flush before any read
    const SkPath& asPath() { flush(); return *this; }

    ~SkCompatPath() { delete fBuilder; }
};

C# switches to sk_compatpath_new() / sk_compatpath_delete():

public SKPath()
    : this(SkiaApi.sk_compatpath_new(), true) { }

[Obsolete("Use SKPathBuilder. SKPath will be immutable in a future version of SkiaSharp.")]
public void LineTo(float x, float y) =>
    SkiaApi.sk_compatpath_line_to(Handle, x, y);

Pros:

• Best potential performance: mutations are O(1) each, batched into the builder
• Flush happens once (O(N)) when the path is read/drawn — total O(N) for building N segments
• Pointer IS-A SkPath* — works with all existing native APIs after flush
• Same proven pattern as SkCompatPaint
• Clear type separation: sk_path_* = real API, sk_compatpath_* = compat

Cons:

• Most code: new C++ class, new C API header/impl, build file changes (pbxproj, GN)
• New opaque type sk_compatpath_t adds complexity
• Flush must be called before any read — every sk_path_* query function and every drawing function that takes a path needs to call AsCompatPath(cpath)->flush() first
• ~30 flush sites across the C API must be patched (query functions, drawing, clipping, path effects, path measure, regions, pathops). Example of what every read site looks like:

  // Before (current):
  void sk_path_get_bounds(const sk_path_t* cpath, sk_rect_t* crect) {
      *crect = ToRect(AsPath(cpath)->getBounds());
  }
  
  // After (with compat flush):
  void sk_path_get_bounds(const sk_path_t* cpath, sk_rect_t* crect) {
      const_cast<SkCompatPath*>(static_cast<const SkCompatPath*>(AsPath(cpath)))->flush();
      *crect = ToRect(AsPath(cpath)->getBounds());
  }

• Functions we don't control also need flush. Any C API function that passes sk_path_t* through to Skia for reading must flush first — including canvas draw, clip, path effects, etc.:

  // sk_canvas.cpp — we'd need to modify this:
  void sk_canvas_draw_path(sk_canvas_t* ccanvas, const sk_path_t* cpath, const sk_paint_t* cpaint) {
      // Must flush before Skia reads the path!
      const_cast<SkCompatPath*>(static_cast<const SkCompatPath*>(AsPath(cpath)))->flush();
      AsCanvas(ccanvas)->drawPath(*AsPath(cpath), *AsPaint(cpaint));
  }
  
  // sk_region.cpp — same:
  bool sk_region_set_path(sk_region_t* r, const sk_path_t* t, const sk_region_t* clip) {
      const_cast<SkCompatPath*>(static_cast<const SkCompatPath*>(AsPath(cpath)))->flush();
      return AsRegion(r)->setPath(*AsPath(t), *AsRegion(clip));
  }
  
  // ... and ~28 more sites

• Risk of stale reads if a flush site is missed — silent wrong behavior (draws old path data), not a crash. Hard to diagnose.
• Every new C API function added in future bumps that takes a path must also remember to flush
• More native code to maintain in the skia fork across future bumps
• Harder to remove in vFuture (C++/C API/build files vs just deleting C# methods)

🛑 Critical Issue: Not all sk_path_t* pointers are SkCompatPath.
Several C API functions return plain sk_path_t* that are NOT backed by SkCompatPath:

• sk_pathbuilder_detach_path() / sk_pathbuilder_snapshot_path() — return plain SkPath
• sk_path_clone() — clones as plain SkPath
• Pathop results (sk_pathop_op, sk_pathop_simplify) — write into plain SkPath
• Font glyph paths (sk_font_get_path) — return plain SkPath

Calling flush() via static_cast<SkCompatPath*> on a plain SkPath* is undefined behavior — it reads memory past the object boundary. Since SkPath has no virtual methods, there's no RTTI to distinguish the types at runtime.

This means either:

1. Every sk_path_t* entering the system must be wrapped in SkCompatPath (complex, allocation overhead), OR
2. A tag/discriminator must be added to the opaque type system (invasive change), OR
3. Flush calls must only happen on paths known to be SkCompatPath (fragile, requires tracking)

None of these are clean. This issue makes Option C impractical without significant additional infrastructure.

Performance Comparison

Operation	Option A (C#)	Option B (C shim)	Option C (lazy)
Single mutation	3 P/Invoke + managed alloc + O(N)	1 P/Invoke + O(N)	1 P/Invoke + O(1)
Build N segments	O(N²) + N managed allocs	O(N²)	O(N)
Read after build	O(1)	O(1)	O(N) flush
Total build+read	O(N²)	O(N²)	O(N)

Note: The O(N²) in Options A/B only matters for large paths built incrementally via the obsolete API. Users who heed the [Obsolete] warning and switch to SKPathBuilder get O(N) regardless. Benchmarking is needed to determine if the constant-factor differences matter for typical path sizes (10-100 segments).

Regardless of Option: Also needed

1. sk_pathbuilder_add_path_reverse — AddPathReverse has no public SkPathBuilder equivalent. Implement via SkPathPriv::ReverseAddPath() (exists at SkPathPriv.h:366, fully implemented at SkPathBuilder.cpp:934). This is needed for all options.

2. GetFillPath / GetSegment dual overloads — keep both SKPathBuilder dst (new preferred) and SKPath dst ([Obsolete] shim) overloads.

3. Rewind() → [Obsolete] alias to Reset() — upstream removed rewind() in m145; the C API already maps it to reset(). The old distinction (rewind kept memory, reset freed it) no longer applies since SkPathData is immutable/ref-counted.

4. Generated files — Skottie, SceneGraph, Resources bindings need regeneration (missing sk_pathbuilder_t alias).

Recommendation

Start with Option B (C shims) for vPR. It has the best balance of simplicity and performance — no managed overhead, no new types, and the C# layer is trivial one-liners that look identical to the old code. The C API functions follow the exact same pattern as the existing sk_path_transform. If benchmarking reveals that the constant-factor differences between A and B don't matter for typical path sizes, Option A (C# shims) is also viable and has the advantage of zero native changes beyond one helper function.

[mattleibow]

SKColorType Enum Renumbering — Unnecessary ABI Break

The PR inserts R16Unorm = 24 in the middle of the SKColorType enum, shifting three existing values:

Member	Before	After
R16Unorm	(new)	24
Rgba10x6	24	25 ⚠️
Bgra10101010XR	25	26 ⚠️
RgbF16F16F16x	26	27 ⚠️

This is a binary/ABI break — any code that serialized these enum values as integers will silently get the wrong color type.

This shouldn't be necessary

SkiaSharp has a two-level enum architecture specifically designed to prevent this:

PUBLIC enum (SKColorType)           ← Stable values, consumer-facing
        ↕  EnumMappings.cs          ← Translates between the two
NATIVE enum (SKColorTypeNative)     ← Generated, mirrors C header exactly
        ↕  P/Invoke
C enum (sk_colortype_t)             ← Skia native

The public SKColorType values are intentionally different from the native sk_colortype_t values. For example, today:

Public	Value	Native	Value
SKColorType.Gray8	9	SKColorTypeNative.Gray8	14
SKColorType.RgbaF16	10	SKColorTypeNative.RgbaF16	16
SKColorType.Alpha16	16	SKColorTypeNative.A16Unorm	22

The mapping in EnumMappings.cs handles the translation. This is the whole point — Skia can reorder its internal enum freely, and as long as we update the mapping, the public API is stable.

Suggested fix

Add R16Unorm at the end of the public enum (value 27) instead of inserting it at 24. Keep existing values stable:

public enum SKColorType
{
    // ... values 0-23 unchanged ...
    R8Unorm = 23,
    Rgba10x6 = 24,         // ← unchanged
    Bgra10101010XR = 25,   // ← unchanged
    RgbF16F16F16x = 26,    // ← unchanged
    R16Unorm = 27,          // ← new, appended at end
}

Then update EnumMappings.cs to map SKColorType.R16Unorm (27) ↔ SKColorTypeNative.R16Unorm (23). The mapping layer already handles mismatched values — that's what it's for.

[mattleibow]

/azp run

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

Azure Pipelines will not run the associated pipelines, because the pull request was updated after the run command was issued. Review the pull request again and issue a new run command.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.

[azure-pipelines]

No pipelines are associated with this pull request.