Bump to google/chrome/m132 (milestone 132)

[ramezgerges]

Description of Change

This PR bumps SkiaSharp's Skia fork to milestone 132. I've tried to keep the changes as reviewable as possible: the branch is mostly the upstream merge from google/chrome/m132, followed by the C API, DEPS, and build adjustments needed to restore the SkiaSharp surface area on top of that newer baseline.

Although the PR is large, it can still be reviewed in the same style as the original draft:

• diff against google/chrome/m132 for the imported upstream Skia changes and dependency rolls
• diff against the prior SkiaSharp-maintained state for the include/c and src/c shim changes that we carry locally

Review Links

• Companion SkiaSharp PR: Bump SkiaSharp to milestone 132 SkiaSharp#3560
• AI review gist: https://gist.github.com/mattleibow/b1c57a78d86cc5dec3fff1182de48f01
• Rendered HTML review: https://gistcdn.githack.com/mattleibow/b1c57a78d86cc5dec3fff1182de48f01/raw/295bb903e36917d3faf80f74ba4d3ab06adcb6ec/171.html

SkiaSharp Issue

Related to mono/SkiaSharp#3560

API Changes

• sk_colortype_t gains BGRA_10101010_XR_SK_COLORTYPE and RGB_F16F16F16X_SK_COLORTYPE, which flow through to the new managed SKColorType values in the companion SkiaSharp PR.
• gr_vk_backendcontext_t, gr_vk_ycbcrconversioninfo_t, and sk_jpegencoder_options_t were adjusted to match upstream ABI changes.
• Upstream removed SkFontMgr::RefDefault(), so this PR adds the sk_default_fontmgr.* shim and related typeface plumbing needed to preserve SkiaSharp's C API behavior.

Behavioral Changes / Why take this bump

This bump is not just about staying current. Between m120 and m132, Skia picked up a set of improvements that map directly to APIs SkiaSharp already exposes today:

• SkCodec::getImage() now respects encoded origin / Exif metadata more consistently, which improves real-world image decode behavior.
• SkCodec::hasHighBitDepthEncodedData, the JPEG orientation work, and newer color-management plumbing improve HDR and wide-gamut image workflows.
• SkImage::makeScaled(...), SkBitmap::setColorSpace(...), and the newer color-aware drop-shadow/filter work improve common image-processing scenarios.
• SkCanvas::SaveLayerRec tilemode support plus the accumulated raster/filter/perlin correctness and performance fixes give us a newer, more capable rendering baseline.

In short: this gives SkiaSharp users a much newer and more capable graphics/runtime base, while also unblocking the follow-on work to expose more of the newer Skia APIs over time.

Required SkiaSharp PR

Requires mono/SkiaSharp#3560

PR Checklist

• Rebased on top of skiasharp at time of PR
• Changes adhere to coding standard
• Updated documentation

[ramezgerges]

@mattleibow I just saw that you opened a PR for milestone 122, so apologies for the timing, I tried to get the changes to a publishable state before opening a PR.
I've done my best to keep the PR reviewable, but let me know if you need any clarifications. While I checked that the main changes (to the source code files) make sense, I'm not that confident about the build files (BUILD.gns, etc.), so you will likely need to take a closer look at those. Thanks.

[mattleibow]

Thanks for putting this together — the m132 jump is a big one.

While reviewing, I ran into an issue with the P/Invoke binding generator (SkiaSharpGenerator). It crashes with IndexOutOfRangeException when processing the anonymous struct type inside gr_vk_ycbcrconversioninfo_t in include/c/sk_types.h:

typedef struct {
    uint32_t  fFormat;
    uint64_t  fExternalFormat;
    uint32_t  fYcbcrModel;
    uint32_t  fYcbcrRange;
    uint32_t  fXChromaOffset;
    uint32_t  fYChromaOffset;
    uint32_t  fChromaFilter;
    uint32_t  fForceExplicitReconstruction;
    uint32_t  fFormatFeatures;
    struct {
        uint32_t  r;
        uint32_t  g;
        uint32_t  b;
        uint32_t  a;
    }         fComponents;
} gr_vk_ycbcrconversioninfo_t;

CppAst (the C parser the generator uses) doesn't handle unnamed struct types nested inside typedefs. The result is a truncated SkiaApi.generated.cs missing ~3200 lines.

I confirmed the fix by extracting the struct — the generator completes successfully after that. The memory layout is the same either way (4 contiguous uint32_ts inline), so the fix is just giving the type a name:

typedef struct {
    uint32_t  r;
    uint32_t  g;
    uint32_t  b;
    uint32_t  a;
} gr_vk_ycbcr_components_t;

typedef struct {
    ...
    uint32_t  fFormatFeatures;
    gr_vk_ycbcr_components_t fComponents;
} gr_vk_ycbcrconversioninfo_t;

This matches the _t typedef convention used elsewhere in the C API and preserves the info.fComponents.r access pattern.

[mattleibow]

@ramezgerges no problem about 122. I am trying to put together a skill/docs on how to do an update. Hopefully some of the boring work can be automated. I am hoping to skip 122 and just do this PR.

[4Darmygeometry]

PR that fix LoongArch64 LSX error: #169

[ramezgerges]

While reviewing, I ran into an issue with the P/Invoke binding generator (SkiaSharpGenerator). It crashes with IndexOutOfRangeException when processing the anonymous struct type inside gr_vk_ycbcrconversioninfo_t in include/c/sk_types.h:

Weird, I tested for multiple platforms and it didn't throw, but done!

I'm sure you have your own process for reviewing massive PRs like this, but here's a quick note nonetheless on how I iterated on the PR in order to keep my (and your) sanity:
I think of this fork as basically two parts: there's the "skiasharp-only" part (part A) which is basically the parts of the repo related to the C api, and then there's the "google's upstream with patches on top of it" part (part B).
The idea I worked with is that the final state should be identical to the current main branch in part A with minimal changes as needed to correspond to the upstream changes in the Skia API and should be identical to google/chrome/m132 in part B except for reapplying patches from main as necessary.
So, to work with this, I would alternate between two diff views:
[1] this PR branch vs a90037 (the last main commit in this branch) + limit the diff to mostly inc/c and src/c. This should give you a smallish diff.
[2] this PR branch vs google/chrome/m132 + ignore inc/c and src/c. This should also give you a smallish-diff.

@mattleibow let me know if you need other details, and thanks for the review!

[mattleibow]

@ramezgerges sounds similar to how I review these ones. I mainly review the diffs. I am currently doing a review, nothing bad so far.

[mattleibow]

🤖 Automated diff report for this Skia bump (chrome/m119 → chrome/m132).

This is a generated summary of fork patch changes, dependency updates, generated binding checks, and companion PR findings — not a code review.

📄 View report · Gist source

[mattleibow]

@ramezgerges I am trying something. I have been working on a script to collect all the actual diffs and output an html file. I have added a comment above with this.

I know there are random other changes in skia - and this has been mostly for the cases where different platforms complained about different things. Like WASM or Tizen wanted consts. Or Google has a bug that I have yet to upstream (the metal one reset/retain). And a couple of ARM64 changes to make platforms work better.

I also have no idea why CI is not triggering so I did it manually here: https://dev.azure.com/xamarin/public/_build/results?buildId=156380&view=results

[ramezgerges]

@mattleibow Pretty cool utility. Here's my response to some points in the html doc. The rest are either addressed, no-longer applicable in m132 or are replaced intentionally with an alternative.

• src/gpu/ganesh/gl/webgl/GrGLMakeNativeInterface_webgl.cpp: the PR dropped a patch to use emscripten_webgl_get_proc_address instead of basically always returning nullptr, but my understanding is that it was never needed because the logic intentionally avoids depending on webgl_get_gl_proc.
• src/opts/SkBlitRow_opts.h: you previously had a patch that adds a (bunch of) const(s), but I prefered to keep the file more faithful to upstream and from what I can tell, CI didn't complain about that.
• **/BUILD.gn, DEPS, Bazel/deps.bzl: Frankly, I don't understand the patches well enough to know which ones should be kept and which should be discarded. When in doubt, I prefered to stick to what upstream had. I will you let you review this part.

[mattleibow]

Audit: GrGLMakeNativeInterface patches — skiasharp branch vs xamarin-m132

The skiasharp branch carries SkiaSharp-specific patches to GL interface factory files. These ensure GrGLMakeNativeInterface() returns nullptr gracefully when no GL context is active (rather than assembling a broken interface that crashes at runtime). The m132 update refactored these files into a GrGLInterfaces::MakePlatform() namespace pattern — some patches survived, some were lost.

Patch origin

Two key commits on the skiasharp branch:

• 10bd203fcc — "Make sure to check for a current GL context" — Added CGLGetCurrentContext check on macOS, eglGetCurrentContext on EGL, and temporarily shared mac impl with iOS
• 042510730b — "Fix the GrGLInterface assembler (Fix the GrGLInterface assembler #81)" — Reverted the iOS=mac sharing (iOS doesn't have CGL), restored iOS to simple dlsym(RTLD_DEFAULT)

Full platform comparison

Platform	File	Context check (skiasharp)	Context check (m132)	Status
Windows	win/GrGLMakeNativeInterface_win.cpp → win/GrGLMakeWinInterface.cpp	✅ wglGetCurrentContext() via GLProcGetter	✅ wglGetCurrentContext_() in new impl	✅ Preserved
macOS	mac/GrGLMakeNativeInterface_mac.cpp	✅ CGLGetCurrentContext() via GLProcGetter — returns nullptr if no context	❌ None — just opens library and assembles	❌ LOST
iOS	iOS/GrGLMakeNativeInterface_iOS.cpp	❌ None (iOS uses EAGLContext, not CGL)	❌ None	✅ OK — never had one
iOS (path bug)	same	Uses dlsym(RTLD_DEFAULT, name)	Opens /System/Library/Frameworks/OpenGL.framework/... (macOS path!)	⚠️ Wrong path — OpenGL.framework doesn't exist on iOS
EGL (Linux/Android)	egl/GrGLMakeNativeInterface_egl.cpp → egl/GrGLMakeEGLInterface.cpp	✅ eglGetCurrentContext()	✅ eglGetCurrentContext() with !SK_USE_WEBGL guard	✅ Preserved
GLX (Linux X11)	glx/GrGLMakeNativeInterface_glx.cpp → glx/GrGLMakeGLXInterface.cpp	✅ glXGetCurrentContext() via GLProcGetter	✅ glXGetCurrentContext() in new impl	✅ Preserved
WebGL (WASM)	webgl/GrGLMakeNativeInterface_webgl.cpp	emscripten_webgl_get_proc_address(name) — full dynamic lookup	Only glGetString hardcoded via macro, SkASSERTF(false) for everything else	⚠️ Changed — see note
Tizen	Uses EGL path	Same as EGL	Same as EGL	✅ Preserved
tvOS	Uses iOS path	Same as iOS	Same as iOS	Same as iOS
Mac Catalyst	Uses iOS path	Same as iOS	Same as iOS	Same as iOS
None (fallback)	GrGLMakeNativeInterface_none.cpp	Returns nullptr	Returns nullptr	✅ Identical

Items to address

1. macOS context check (LOST) — The m132 GrGLInterfaces::MakeMac() no longer checks CGLGetCurrentContext(). Without this, calling GrGLMakeNativeInterface() when no GL context is current will attempt to assemble an interface that may crash when used. The skiasharp patch returned nullptr early so the C# layer could handle "no GL available" gracefully.

2. iOS OpenGL.framework path (BUG) — The m132 iOS implementation tries to dlopen("/System/Library/Frameworks/OpenGL.framework/...") which is a macOS-only path. The skiasharp version correctly used dlsym(RTLD_DEFAULT, name). This may cause iOS GL initialization to fail (falling back to RTLD_DEFAULT via the ctx ? ctx : RTLD_DEFAULT ternary, so it might work by accident).

3. WebGL proc lookup (CHANGED) — The upstream m132 approach hardcodes glGetString and uses GrGLMakeAssembledWebGLInterface (which uses compile-time linked symbols via GR_GL_CORE_FUNCTIONS_EACH). The skiasharp approach used emscripten_webgl_get_proc_address() for runtime lookup. The m132 approach is actually upstream's intended direction (see comment in code about code size), but needs verification that GrGLMakeAssembledWebGLInterface covers all needed functions.

Windows ARM64

Commit f8ba1c589c ("Enable GL on Windows ARM #151") removed the #if defined(_M_ARM64) return nullptr; guard. The new m132 GrGLMakeWinInterface.cpp doesn't have this guard either, so Windows ARM64 GL support is preserved. ✅

[ramezgerges]

@mattleibow Done. These slipped by me, apologies.

[4Darmygeometry]

FAILED: libSkiaSharp.so.132.0.0
clang++-19 -shared -Wl,--no-undefined -Wl,--gc-sections -static-libstdc++ -static-libgcc -Wl,--version-script=/work/native/linux/libSkiaSharp/libSkiaSharp.map --target=loongarch64-linux-gnu -B/usr/loongarch64-linux-gnu/bin/ -L/usr/loongarch64-linux-gnu/lib/ -Wl,--start-group @libSkiaSharp.so.132.0.0.rsp -Wl,--end-group -lpthread -lfontconfig -ldl -Wl,-soname,libSkiaSharp.so.132.0.0 -o libSkiaSharp.so.132.0.0
/usr/loongarch64-linux-gnu/bin/ld: libskia.a(libpng.pngrutil.o): in function png_read_filter_row': pngrutil.c:(.text.png_read_filter_row+0x9c): undefined reference to png_init_filter_functions_lsx'
/usr/loongarch64-linux-gnu/bin/ld: libskia.a(libskia.SkOpts.o): in function SkOpts::Init()': SkOpts.cpp:(.text._ZN6SkOpts4InitEv+0x50): undefined reference to SkOpts::Init_lasx()'
clang++-19: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
An error occurred when executing task 'libSkiaSharp'.
Error: Process 'python3' failed with error: 1
An error occurred when executing task 'libSkiaSharp'.
Error: .NET CLI: Process returned an error (exit code 1).
An error occurred when executing task 'externals-linux-clang-cross'.
Error: .NET CLI: Process returned an error (exit code 1).

##[error]Bash exited with code '1'.

[4Darmygeometry]

FAILED: libSkiaSharp.so.132.0.0
clang++-19 -shared -Wl,--no-undefined -Wl,--gc-sections -static-libstdc++ -static-libgcc -Wl,--version-script=/work/native/linux/libSkiaSharp/libSkiaSharp.map --target=loongarch64-linux-gnu -B/usr/loongarch64-linux-gnu/bin/ -L/usr/loongarch64-linux-gnu/lib/ -Wl,--start-group @libSkiaSharp.so.132.0.0.rsp -Wl,--end-group -lpthread -lfontconfig -ldl -Wl,-soname,libSkiaSharp.so.132.0.0 -o libSkiaSharp.so.132.0.0
/usr/loongarch64-linux-gnu/bin/ld: libskia.a(libpng.pngrutil.o): in function png_read_filter_row': pngrutil.c:(.text.png_read_filter_row+0x9c): undefined reference to png_init_filter_functions_lsx'
/usr/loongarch64-linux-gnu/bin/ld: libskia.a(libskia.SkOpts.o): in function SkOpts::Init()': SkOpts.cpp:(.text._ZN6SkOpts4InitEv+0x50): undefined reference to SkOpts::Init_lasx()'
clang++-19: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
An error occurred when executing task 'libSkiaSharp'.
Error: Process 'python3' failed with error: 1
An error occurred when executing task 'libSkiaSharp'.
Error: .NET CLI: Process returned an error (exit code 1).
An error occurred when executing task 'externals-linux-clang-cross'.
Error: .NET CLI: Process returned an error (exit code 1).

##[error]Bash exited with code '1'.

@ramezgerges @mattleibow Failed to build LoongArch64 nuget package
see:https://dev.azure.com/xamarin/public/_build/results?buildId=156616&view=logs&j=fbd80fd1-ae5e-5e01-4fbe-e61fd2b01845&t=6bb9bb25-6712-541e-a045-89609f0b804f

[mattleibow]

@4Darmygeometry thanks. I think I fixed it. Please try testing the nugets on loong64 once CI is done so we can know if we got that right.

[4Darmygeometry]

@4Darmygeometry thanks. I think I fixed it. Please try testing the nugets on loong64 once CI is done so we can know if we got that right.

OK