[skia-sync] Update skia to milestone 150#4146
Conversation
- Bumped milestone from m148 to m150 - Updated NuGet version from 4.148.0 to 4.150.0 - Updated cgmanifest.json with new commit hash and chrome_milestone=150 - Updated submodule to merged m150 branch Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
📦 Try the packages from this PRWarning 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 -- 4146PowerShell / Windows: iex "& { $(irm https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.ps1) } 4146"Step 2 — Add the local NuGet source dotnet nuget add source ~/.skiasharp/hives/pr-4146/packages --name skiasharp-pr-4146More options
Or download manually from Azure Pipelines — look for the Remove the source when you're done: dotnet nuget remove source skiasharp-pr-4146 |
|
📖 Documentation Preview The documentation for this PR has been deployed and is available at: 🔗 View Staging Site This preview will be updated automatically when you push new commits to this PR. This comment is automatically updated by the documentation staging workflow. |
Advances externals/skia to 047210c1bf which removes the fork-only // TODO(kjlubick) comment in tests/RegionTest.cpp so the file matches upstream chrome/m150 exactly. Updates cgmanifest.json commit hash to match. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Three platform-specific native build failures on Azure DevOps build 158198: - Windows: m150's SkFontMgr_win_dw.cpp onMatch() uses IDWriteFontSet4, which requires Windows 11 SDK 10.0.22621. Skia's GN picks the lowest installed SDK >= 10.0.16299, so it resolved to an older SDK and failed with 'use of undeclared identifier IDWriteFontSet4'. Pin win_sdk_version='10.0.22621.0' (preinstalled on the windows-2022 image). Runtime-safe: IDWriteFontSet4 is acquired via QueryInterface with a null-check fallback, and a newer SDK adds no new DLL import. - WASM/Tizen: bump skia submodule to replace std::views::reverse in SkPDFTag.cpp with a reverse-iterator loop (emscripten 3.1.34 / libc++ 15 disables ranges) and guard the PDF C API with SK_SUPPORT_PDF. - Tizen: clang 10 + gcc 9.2 libstdc++ predate C++20 (<compare>/ranges required by m150's PDF backend), so disable PDF with skia_enable_pdf=false as an agreed stopgap. Regresses SKDocument PDF on Tizen, tracked by #4155. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Rather than pinning win_sdk_version='10.0.22621.0' exactly, raise min_win_sdk_version to 10.0.22621.0. Skia's gn/BUILDCONFIG.gn selects the lowest installed SDK >= min_win_sdk_version via lowest_version_dir.py, so this picks 22621 when present and tolerates a newer SDK if the exact version isn't installed on the agent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Bump skia submodule to d2fe11b410: - mono/skia #255: C++17 backport of the PDF backend's three-way comparisons (SkPDFTypes.h, SkPDFTag.cpp), so PDF compiles on the Tizen clang-10/gcc-9.2 toolchain. Removes the skia_enable_pdf=false stopgap from native/tizen/build.cake, restoring SKDocument PDF on Tizen. Fixes #4155. - Raise min_win_sdk_version to 10.0.22621.0 in skia's gn/BUILDCONFIG.gn (for IDWriteFontSet4) instead of threading a gn arg through build.cake, so the requirement lives with the source that needs it. Reverts the earlier cake-level win_sdk arg. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Roll skia to 144ebf96d5 which fixes the C++17 PDF backport's use of std::optional<Data>::emplace on an aggregate type, which failed to compile on the Tizen gcc-9.2 libstdc++ toolchain. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Roll skia to a8ea924948 so the m150 ml3/ml4 SkOpts use clang-10-compatible -march names (haswell / skylake-avx512) on Tizen x86_64, which clang 10 rejects under the new x86-64-v3 / x86-64-v4 CPU names. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Re-pin externals/skia to 159b1ec9e5 which fixes the m150 D3D backend abstract-class / override errors in GrD3DBackendSurface.cpp on the Windows native build. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Re-pin externals/skia to bceb12ad2c which reverts the SK_SUPPORT_PDF guard that broke PDF document creation on all platforms (the define never reaches the C API translation unit compiled into :core). Fixes SKDocumentTest PDF failures. PDF is enabled on every platform now (#4155). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
[skia-sync] Merge upstream chrome/m150 (#253) Context: https://skia.googlesource.com/skia/+log/chrome/m150 Changes: skiasharp...skia-sync/m150 Companion: mono/SkiaSharp#4146 Fixes: mono/SkiaSharp#4155 Advance the SkiaSharp fork's Skia engine from Chrome milestone 148 to 150 by merging upstream chrome/m150 (tip c925145) into skia-sync/m150 on top of the fork's skiasharp branch (1a155ba). Merge commit 0a248d1 resolved 19 conflicts; the fork's intentional deltas were preserved while taking upstream's behavior everywhere the fork had no opinion. Notable conflict resolutions: * DEPS: kept the fork's pinned native deps (expat 2.8.1, freetype 2.14.3, harfbuzz 14.2.0, libjpeg-turbo, libpng, libwebp, zlib) — upstream would have downgraded these security/bug-fix bumps. * include/core/SkFont.h: kept the fork's breakText() overloads and added upstream's new SkStrikeRef makeStrikeRef(). * src/gpu/ganesh/ops/AtlasTextOp.cpp: combined the fork's glyphSrcPadding()>0 guard with upstream's supportsBilerp() condition, taking upstream's graceful log+return on stride mismatch instead of the prior hard assert. ~~ Post-merge portability fixes ~~ The raw merge compiles on the primary toolchains, but SkiaSharp's CI builds the native libraries on toolchains upstream Skia CI does not exercise: WASM (emscripten 3.1.34 / libc++ 15), Tizen (clang 10 + gcc 9.2 libstdc++), and the Direct3D Ganesh backend on Windows. Those legs failed until the following fixes landed on top of the merge: * 8912293 — WASM/Tizen: rewrite std::views::reverse in SkPDFTag.cpp as a reverse-iterator loop; ranges/std::views are gated off in libc++ 15 and unavailable in clang 10. * d0b422e (PR #255) — Tizen: backport the PDF backend's C++20 three-way comparisons (<=>/==) to explicit C++17 operators in SkPDFTypes.h and SkPDFTag.cpp; the Tizen libstdc++ predates <compare>. This keeps PDF enabled on Tizen with no regression and resolves SkiaSharp #4155. * 144ebf9 — Tizen: replace optional::emplace on an aggregate with aggregate-init for libstdc++ 9.2. * a8ea924 — Tizen: opts("ml3")/opts("ml4") use clang-10-spellable -march=haswell / skylake-avx512 (keeping m150's new -mprefer-vector-width=512). m150 switched to -march=x86-64-v3/v4, which clang only understands from version 12. * d2fe11b — Windows: raise min_win_sdk_version to 10.0.22621.0 in gn/BUILDCONFIG.gn (a floor, not a pin) so the MSVC toolchain selects the Win11 SDK that defines IDWriteFontSet4, used by m150's SkFontMgr_win_dw.cpp. The interface is acquired via QueryInterface with a null-check fallback, so older Windows at runtime is unaffected. * 159b1ec — Windows D3D: declare GrD3DBackendFormatData::equal unconditionally and fully guard GrD3DBackendTextureData::equal under GPU_TEST_UTILS. Completes upstream 20c3044, which left the D3D backend abstract in non-test builds; only SkiaSharp compiles the D3D backend, so upstream CI never caught it. * bceb12a — All platforms: revert a SK_SUPPORT_PDF guard added to src/c/sk_document.cpp. The SkiaSharp C-API shim compiles into Skia's :core target, which never receives :pdf's SK_SUPPORT_PDF public define, so the guard was always false and the PDF factories returned null everywhere (caught by SKDocumentTest). These are toolchain/portability changes only — no change to Skia rendering behavior on any platform. The companion SkiaSharp PR #4146 re-pins the submodule to bceb12a, and Azure DevOps "SkiaSharp (Public)" build 158224 is green across all stages (native Windows/macOS/Linux/WASM, package, API diff, managed build, tests, samples). Co-authored-by: Matthew Leibowitz <mattleibow@live.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
mono/skia PR #253 merged the chrome/m150 update into the stable `skiasharp` branch as merge commit 94451aa283 (parents 1a155bae3a + bceb12ad2c). Point the submodule at that merge commit instead of the now-merged integration-branch tip bceb12ad2c; the tree content is identical, but this tracks the stable branch. Also fix the stale "Main Skia repository reference" commitHash in cgmanifest.json, which still pointed at the first fork commit (047210c1bf), to the same merge commit. chrome_milestone (150) and upstream_merge_commit (c92514572e, the chrome/m150 tip) are unchanged and correct. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Bumps SkiaSharp’s pinned Skia dependency from Chrome milestone m148 to m150 and updates the repo’s version metadata to align (NuGet/package versions, build pipeline variables, and component governance tracking).
Changes:
- Updated
scripts/VERSIONS.txtto milestone 150 and bumped SkiaSharp NuGet/package versions to4.150.0(plus soname/version fields). - Updated Azure pipeline template variables to use
SKIASHARP_VERSION: 4.150.0. - Updated
cgmanifest.jsonto reflect the new mono/skia commit hash and milestone tracking metadata (chrome_milestone,upstream_merge_commit).
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| scripts/VERSIONS.txt | Updates milestone/soname/assembly/file/NuGet version metadata to m150 / 4.150.0. |
| scripts/azure-templates-variables.yml | Bumps SKIASHARP_VERSION used by Azure pipeline build numbering to 4.150.0. |
| cgmanifest.json | Updates component governance entries for the Skia git commit and chrome milestone tracking to m150. |
Automated Skia milestone bump from m148 to m150.
Companion skia PR: mono/skia#253
mono/SkiaSharp PR Summary: Skia m148 → m150 Binding Update
Overview
Updated SkiaSharp parent repository to use the newly merged Skia m150 submodule. This is a version bump with no breaking C API or C# changes.
Version Changes
scripts/VERSIONS.txtcgmanifest.jsoncommitHashupdated to94451aa283,chrome_milestone= 150,upstream_merge_commit=c92514572escripts/azure-templates-variables.ymlSKIASHARP_VERSION= 4.150.0externals/skia94451aa283(mono/skia PR #253 merge commit onskiasharp; m150 merge0a248d1b82+ portability fixes — see below)SK_C_INCREMENT
SK_C_INCREMENTwas reset to0by the update-versions script on milestone change (was already0). No new C API functions were added in this update.C API Changes
None. The binding generator (
regenerate-bindings.ps1) confirmed no changes toSkiaApi.generated.csbetween m148 and m150.C# Wrapper Changes
None. No new generated functions were detected requiring hand-written C# wrapper code.
Breaking Change Analysis
SkRegion::setRectssignatureSkShader::isOpaque()pure virtualSkStrikeRefnew typePost-Merge CI / Portability Fixes
After the initial merge, the Azure DevOps native source build (
SkiaSharp (Public)) surfaced toolchain-specific compile failures on Windows, WASM, and Tizen. These were fixed in the companion skia fork PR #253 (commits on top of the m150 merge) and the submodule was re-pinned forward to94451aa283(the PR #253 merge commit on theskiasharpbranch). Summary of the fork fixes now included:std::views::reverse→ reverse-iterator loop inSkPDFTag.cppstd::ranges/std::viewsgated behind incomplete-features in libc++ 15SkPDFTypes.h,SkPDFTag.cpp);optional::emplaceon aggregate → aggregate-init<compare>/ranges. Resolves #4155; PDF stays enabled on Tizen (no regression)opts("ml3")/opts("ml4")use clang-10-march=haswell/skylake-avx512(keeping m150's new-mprefer-vector-width=512)-march=x86-64-v3/v4, which clang 10 doesn't know (clang ≥ 12)min_win_sdk_version = "10.0.22621.0"floor in skiagn/BUILDCONFIG.gnSkFontMgr_win_dw.cppusesIDWriteFontSet4, which needs the Win11 SDK (acquired viaQueryInterfacewith null-check fallback — runtime-safe on older Windows)GrD3DBackendSurface.cpp:GrBackendFormatData::equalmade unconditional,GrBackendTextureData::equalfully guarded underGPU_TEST_UTILS20c304440c, which left the D3D backend abstract in non-test builds. Only SkiaSharp compiles the D3D backend, so upstream CI never caught itSK_SUPPORT_PDFguard insrc/c/sk_document.cpp:coretarget, which never receives:pdf'sSK_SUPPORT_PDFpublic define → guard was always false → PDF factories returned null everywhere (caught bySKDocumentTest)Build Results
externals-linux x64)libSkiaSharp.so.150.0.0✅libHarfBuzzSharp.so✅dotnet build binding/SkiaSharp/SkiaSharp.csproj✅ (0 errors, 0 warnings)SkiaSharp (Public)build 158224 — all stages green (Native Windows/macOS/Linux/WASM, Native, Package NuGets, API Diff, Build Managed, Tests, Samples).Test Results
All 172 skipped tests are expected platform/hardware skips (GPU tests without GPU drivers, platform-specific features). Zero failures.
Full test output:
test-output.txt(workflow artifact)Items Needing Human Attention
No C# API additions for
SkStrikeRef: Upstream addedSkFont::makeStrikeRef()returning the newSkStrikeReftype. This is not yet exposed in the C API or C# bindings. Could be tracked as a future API addition issue if users request it.DEPS pinning carries forward: Fork maintains custom-pinned native library versions (expat 2.8.1, freetype 2.14.3, harfbuzz 14.2.0, etc.) which are security/bug-fix upgrades vs upstream. These remain correct.
Created by skia-upstream-sync.