basalt-win32 0.0.0-stage → 0.2.0

package/native/win32/Win32ScrollView.h

@@ -0,0 +1,256 @@
+// <ScrollView> on Win32.
+//
+// Yoga does the hard part. A ScrollView's Yoga node carries `overflow: scroll`,
+// which lets its child exceed the viewport instead of being clamped to it, so
+// by the time a mutation arrives the content is already laid out at its full
+// size and the only thing missing is the offset.
+//
+// Structure: a mounted ScrollView has exactly **one** child, a content view.
+// React Native's JS wraps the children in an `RCTScrollContentView`, which the
+// C++ registry rewrites to a plain `View`, so no extra descriptor is needed and
+// nothing here should expect N children.
+//
+// Scrolling is `RnWin32View::setScrollOffset`, which shifts children while
+// painting rather than moving them. The frames the mounting manager wrote stay
+// exactly the ones Yoga produced, nothing has to be undone on the next
+// mutation, and `hitTest` adds the same offset back on the way down -- so
+// picking follows the scroll without knowing what a ScrollView is. GTK reaches
+// the same place by shifting children in its layout manager and AppKit by
+// moving `bounds.origin`.
+//
+// Two things must happen on every scroll, and they are not the same thing:
+//
+//   - `onScroll` goes to JavaScript, throttled by `scrollEventThrottle`. Without
+//     it VirtualizedList never renders past its first window.
+//   - `contentOffset` is written back into `ScrollViewState`, unthrottled.
+//     `ScrollViewShadowNode::getContentOriginOffset` reads it, and through that
+//     so do `measure`, `measureLayout`, C++ hit testing and view culling. Skip
+//     it and those all silently report unscrolled coordinates.
+//
+// All of that is the same on all three desktops, which is why this file reads
+// like GtkScrollView.cpp with different event plumbing.
+//
+// ## What is different here
+//
+// **Routing.** GTK attaches a `GtkEventControllerScroll` per widget and AppKit
+// walks the responder chain; both get "a wheel over a row scrolls the list
+// containing it, and a list inside a list scrolls the inner one first" for
+// free. A Win32 view has no window of its own and there is no chain to walk, so
+// `scrollAt` does it: hit test for the view under the pointer, then walk up
+// parents offering the wheel to each ScrollView until one takes it. The first
+// that does is the innermost, which is the same answer the other two get.
+//
+// **Drag phases.** GTK's controller reports scroll-begin and scroll-end, and
+// AppKit's NSEvent carries a phase. Win32 has neither: `WM_MOUSEWHEEL` is a
+// bare notch with nothing around it. So a run of wheel messages is treated as
+// one drag, ended by a short idle timeout -- see `kWheelIdleMs`. Without that
+// there would be no `onScrollBeginDrag` or `onScrollEndDrag` on this platform
+// at all, and the components that wait for them would wait forever.
+//
+// What Windows does not have: momentum. `onMomentumScrollBegin` and
+// `onMomentumScrollEnd` never fire here, and that is deliberate rather than
+// unfinished. A precision touchpad reports `WM_MOUSEWHEEL` with fine deltas and
+// no fling velocity -- inertia on Windows belongs to Direct Manipulation, which
+// wants to own the viewport and so cannot be used by a platform whose whole
+// invariant is that React Native decides where things go. macOS gets momentum
+// from the system and GTK gets a velocity this project animates
+// (core/ScrollMomentum.h); a wheel supplies neither, and modelling a fling off
+// one would report a throw that never happened.
+
+#pragma once
+
+#include "ScrollAnimation.h"
+#include "ScrollBounds.h"
+#include "ScrollIndicator.h"
+#include "ScrollSnap.h"
+#include "ScrollVisiblePosition.h"
+#include "RnWin32View.h"
+
+#include <react/renderer/components/scrollview/ScrollViewShadowNode.h>
+#include <react/renderer/core/EventEmitter.h>
+#include <react/renderer/mounting/ShadowView.h>
+
+#include <cstdint>
+#include <functional>
+#include <optional>
+#include <string>
+#include <unordered_map>
+#include <vector>
+
+namespace basalt {
+
+class Win32ScrollViewManager {
+ public:
+  // Emitters live in the mounting manager's registry, which is also what owns
+  // this, so they are reached through a lookup rather than a second copy.
+  using EmitterLookup = std::function<facebook::react::EventEmitter::Shared(facebook::react::Tag)>;
+
+  explicit Win32ScrollViewManager(EmitterLookup lookup);
+  ~Win32ScrollViewManager();
+
+  Win32ScrollViewManager(const Win32ScrollViewManager &) = delete;
+  Win32ScrollViewManager &operator=(const Win32ScrollViewManager &) = delete;
+  Win32ScrollViewManager(Win32ScrollViewManager &&) = delete;
+  Win32ScrollViewManager &operator=(Win32ScrollViewManager &&) = delete;
+
+  // Called for every mutation touching a ScrollView. Registers the view the
+  // first time, and refreshes the geometry and props after.
+  void update(win32::RnWin32View *view, const facebook::react::ShadowView &shadowView);
+
+  void remove(facebook::react::Tag tag);
+  // `maintainVisibleContentPosition`, in the two halves a mounting transaction
+  // needs: the children are measured before the mutations and the offset is
+  // moved after, so content under the eye stays where it is while items are
+  // inserted above it. The arithmetic is core/ScrollVisiblePosition.h's.
+  //
+  // Public because the mounting manager is what knows when a transaction starts
+  // and ends, which is upstream's division too: `mountingTransactionWillMount`
+  // and `...DidMount` on iOS.
+  void prepareMaintainVisiblePosition();
+  void adjustForMaintainVisiblePosition();
+
+
+  // ScrollView's imperative commands: scrollTo, scrollToEnd. Returns false if
+  // the command is not one this handles.
+  bool dispatchCommand(facebook::react::Tag tag,
+                       const std::string &name,
+                       const folly::dynamic &args);
+
+  // The wheel, in pixels already: a notch is resolved against kWheelStepPixels
+  // by the caller, because only the message knows how many notches it was. The
+  // point is in `root`'s coordinates. Returns false when nothing under it
+  // scrolls, which is what lets the host leave the message to DefWindowProc.
+  bool scrollAt(win32::RnWin32View *root, double x, double y, double dx, double dy);
+
+  // A wheel notch carries no pixel distance of its own, so a step has to be
+  // chosen. Roughly three lines of 16pt text, which is what browsers and both
+  // other desktops settle on -- and, at 96 DPI, close to what Windows' own
+  // three-line default works out to. Public because the host resolves notches
+  // into pixels before calling, and the two must use one number.
+  //
+  // Deliberately not `SPI_GETWHEELSCROLLLINES`. Honouring it would be the more
+  // native thing and would make one notch move a different distance here than
+  // on the other two desktops, which is the trade this project keeps making the
+  // other way: matching the other platform matters more than matching the
+  // toolkit's own default.
+  static constexpr double kWheelStepPixels = 53.0;
+
+  // The pull past the top of the list, which is what a <RefreshControl> is
+  // waiting for. Called with how far past the top this scroll asked to go, or
+  // with zero when the gesture went the other way or the view actually moved --
+  // which re-arms it. See core/PullToRefresh.h for why a desktop has to count
+  // this rather than measure a rubber band.
+  void setOverscrollTopHandler(std::function<void(facebook::react::Tag, double)> handler) {
+    overscrollTop_ = std::move(handler);
+  }
+
+ private:
+  std::function<void(facebook::react::Tag, double)> overscrollTop_;
+
+  struct Entry {
+    win32::RnWin32View *view{nullptr};
+    facebook::react::Tag tag{0};
+
+    // An animated `scrollTo`. Windows models no fling -- a wheel supplies no
+    // velocity -- but an animated scroll is given its target, so the argument
+    // that rules out momentum does not rule this out. Driven by a thread timer,
+    // which needs no window: the scroll manager has a tag, not an HWND.
+    ScrollSnapConfig snap;
+    ScrollAnimation animation;
+    UINT_PTR animationTimer{0};
+    unsigned long long animationLastMillis{0};
+
+    std::shared_ptr<const facebook::react::ScrollViewShadowNode::ConcreteState> state;
+
+    facebook::react::Size contentSize{};
+    facebook::react::Size containerSize{};
+    // `contentInset` changes how far the view scrolls;
+    // `scrollIndicatorInsets` changes only where the bar is drawn. See
+    // core/ScrollBounds.h.
+    facebook::react::EdgeInsets contentInset{};
+    facebook::react::EdgeInsets indicatorInset{};
+
+    bool scrollEnabled{true};
+    // `showsVerticalScrollIndicator` / `showsHorizontalScrollIndicator`. Both
+    // default to true, as React Native's own props do.
+    bool showsVerticalIndicator{true};
+    bool showsHorizontalIndicator{true};
+    // Milliseconds, as React Native's prop is. Zero means every scroll.
+    double eventThrottleMs{0};
+
+    double offsetX{0};
+    double offsetY{0};
+
+    // `maintainVisibleContentPosition`, as React Native hands it over: a
+    // minimum index and an optional threshold, or nothing at all when the list
+    // never asked.
+    std::optional<facebook::react::ScrollViewMaintainVisibleContentPosition> maintainVisible{};
+    // The child being held still across the current transaction, measured by
+    // `prepareMaintainVisiblePosition` and used by the adjust that follows.
+    ScrollPinnedChild pinned{};
+    // `indicatorStyle`: which colour the overlay thumb is drawn in. Held as
+    // core's enum rather than React Native's, the view layer below knowing
+    // nothing about either.
+    ScrollIndicatorStyle indicatorStyle{ScrollIndicatorStyle::Default};
+
+    // `centerContent`: whether content smaller than the container is centred in
+    // it. Acted on through the content inset, which is how iOS does it too --
+    // see `update`.
+    bool centerContent{false};
+
+    // The last `contentOffset` prop seen, and nothing when none has been.
+    //
+    // The *initial* value of that prop arrives through the state rather than
+    // here -- `ScrollViewShadowNode::initialStateData` seeds the state with it
+    // -- and is adopted below. What this is for is every later change, which
+    // arrives as an ordinary prop update and is applied when it *changes*,
+    // never merely when it differs from where the list is: an app that sets the
+    // prop once and re-renders for an unrelated reason must not have the list
+    // dragged back under the person reading it. The same rule a `<TextInput>`'s
+    // `text` is under, for the same reason.
+    std::optional<facebook::react::Point> lastPropContentOffset{};
+    double lastEmitMs{0};
+
+    bool dragging{false};
+    // Bumped on every wheel. An idle timer that wakes and finds a different
+    // value knows another notch arrived after it was scheduled, and leaves the
+    // drag alone.
+    std::uint64_t wheelGeneration{0};
+  };
+
+  bool scrollEntry(Entry &entry, double dx, double dy);
+  void endWheelDrag(facebook::react::Tag tag, std::uint64_t generation);
+
+  // The rows of the content view, on whichever axis scrolls, for
+  // `maintainVisibleContentPosition`. The one part of that prop a toolkit
+  // knows: core decides what to do with the boxes.
+  std::vector<ScrollChildBox> contentChildBoxes(const Entry &entry) const;
+
+  void applyOffset(Entry &entry, double x, double y, bool emitEvent);
+  // Recomputes both overlay scrollbars and hands them to the view to draw.
+  // Called wherever the offset, the content size or the container size can
+  // have changed, which is more places than the offset alone.
+  void updateIndicators(const Entry &entry);
+  void scrollTowards(Entry &entry, double x, double y, bool animated);
+  bool settleOnSnapPoint(Entry &entry, double velocityY);
+  void stopAnimation(Entry &entry);
+  void advanceAnimation(facebook::react::Tag tag, double seconds);
+
+  // The timer procedure cannot carry a pointer, so it looks the animation up by
+  // timer id. Static because `SetTimer` calls a plain function.
+  static void CALLBACK onAnimationTimer(HWND hwnd, UINT message, UINT_PTR id, DWORD now);
+  void emitScrollEvent(Entry &entry, const char *which);
+  void writeStateOffset(const Entry &entry);
+
+  EmitterLookup lookup_;
+  std::unordered_map<facebook::react::Tag, Entry> entries_;
+
+  // Cleared by the destructor, and held by every idle timer in flight. A timer
+  // that outlives this object -- a surface torn down inside the 150ms after the
+  // last notch -- finds the flag false and does nothing, instead of calling
+  // through a dangling `this`. The same arrangement Win32ImageLoader uses for
+  // the same reason, which is that `postDelayed` has no cancel.
+  std::shared_ptr<bool> alive_ = std::make_shared<bool>(true);
+};
+
+} // namespace basalt

package/native/win32/Win32SkiaContext.cpp

@@ -0,0 +1,221 @@
+#include "Win32SkiaContext.h"
+
+#include "ImageBytes.h"
+#include "PlatformServices.h"
+
+#include <windows.h>
+
+#include "include/core/SkData.h"
+#include "include/core/SkFontMgr.h"
+#include "include/core/SkImage.h"
+#include "include/core/SkStream.h"
+#include "include/core/SkSurface.h"
+#include "include/core/SkTypeface.h"
+#include "include/ports/SkTypeface_win.h"
+
+#include <glog/logging.h>
+
+#include <cstdint>
+#include <memory>
+#include <stdexcept>
+#include <string>
+#include <thread>
+#include <utility>
+#include <vector>
+
+namespace basalt {
+namespace {
+
+class Win32SkiaPlatformContext : public RNSkia::RNSkPlatformContext {
+ public:
+  Win32SkiaPlatformContext(std::shared_ptr<facebook::react::CallInvoker> callInvoker,
+                           float pixelDensity)
+      : RNSkia::RNSkPlatformContext(std::move(callInvoker), pixelDensity) {}
+
+  // ---------------------------------------------------------------- threading
+
+  void runOnMainThread(std::function<void()> func) override {
+    // basalt's own, so Skia's idea of the main thread and this host's are the
+    // same one. Fire and forget, which is all `postToUiThread` offers and all
+    // this seam promises.
+    postToUiThread(std::move(func));
+  }
+
+  // ------------------------------------------------------------------- errors
+
+  void raiseError(const std::exception &err) override {
+    // Logged, not fatal, as on AppKit: the package's Apple version calls
+    // RCTFatal and takes the app down with a red box, and a shader that fails
+    // to compile is not a reason to end a session.
+    LOG(ERROR) << "react-native-skia: " << err.what();
+  }
+
+  // ----------------------------------------------------------------- surfaces
+
+  sk_sp<SkSurface> makeOffscreenSurface(int width, int height,
+                                        bool useP3ColorSpace = false) override {
+    // The colour space is accepted and not honoured: a Display P3 surface is a
+    // wide-gamut answer for a host that has no colour management of its own
+    // yet, and silently returning sRGB is the same picture on a machine that
+    // is not wide-gamut. Named here so the day it matters, this is the line.
+    (void)useP3ColorSpace;
+    // CPU. See Win32SkiaContext.h for why this host is raster: everything the
+    // imperative API does -- paths, decoded images, typefaces -- works here,
+    // and so does `<Canvas>`, which draws into one of these and is then copied
+    // into the Direct2D walk by win32/Win32SkiaPeer.h.
+    return SkSurfaces::Raster(SkImageInfo::MakeN32Premul(width, height));
+  }
+
+  GrDirectContext *getDirectContext() override {
+    // Null is a documented answer rather than a failure: Skia's own call sites
+    // either skip the GPU path for a raster image or say "No GPU context
+    // available" by name. What must not happen is inventing a context that
+    // draws nowhere.
+    return nullptr;
+  }
+
+  // ------------------------------------------------------------------- images
+
+  sk_sp<SkImage> makeImageFromNativeBuffer(void *) override {
+    throw std::runtime_error(unsupportedNativeBuffers());
+  }
+
+  sk_sp<SkImage> makeImageFromNativeTexture(const RNSkia::TextureInfo &, int, int,
+                                            bool) override {
+    throw std::runtime_error(unsupportedTextures());
+  }
+
+  const RNSkia::TextureInfo getTexture(sk_sp<SkImage>) override {
+    throw std::runtime_error(unsupportedTextures());
+  }
+
+  const RNSkia::TextureInfo getTexture(sk_sp<SkSurface>) override {
+    throw std::runtime_error(unsupportedTextures());
+  }
+
+  // -------------------------------------------------------------------- fonts
+
+  sk_sp<SkFontMgr> createFontMgr() override {
+    // DirectWrite, which is what the Windows archives are built with -- the GN
+    // args turn freetype and fontconfig off, where the Linux build turns them
+    // on. Same seam, each platform's real font system.
+    return SkFontMgr_New_DirectWrite();
+  }
+
+  std::vector<std::string> getSystemFontFamilies() override {
+    std::vector<std::string> families;
+    const sk_sp<SkFontMgr> manager = createFontMgr();
+    if (manager == nullptr) {
+      return families;
+    }
+    const int count = manager->countFamilies();
+    families.reserve(static_cast<size_t>(count));
+    for (int i = 0; i < count; i++) {
+      SkString name;
+      manager->getFamilyName(i, &name);
+      families.emplace_back(name.c_str());
+    }
+    return families;
+  }
+
+  // -------------------------------------------------------------------- media
+
+  std::shared_ptr<RNSkia::RNSkVideo> createVideo(const std::string &) override {
+    // The package's video is AVFoundation on Apple and MediaCodec through JNI
+    // on Android; neither exists here. Media Foundation is the Windows answer
+    // and is its own piece of work -- the same conclusion kino's own audio
+    // module reached for the same reason.
+    throw std::runtime_error(
+        "react-native-skia: video is not implemented on this host. It needs Media "
+        "Foundation, which nothing here wraps yet.");
+  }
+
+  // ------------------------------------------------------------------ loading
+
+  void performStreamOperation(
+      const std::string &sourceUri,
+      const std::function<void(std::unique_ptr<SkStreamAsset>)> &op) override {
+    // On a thread, because callers treat this as asynchronous and the operation
+    // may read from the network. Detached for the same reason the package's is:
+    // the continuation is the completion.
+    //
+    // Through core's own fetcher rather than a second one written here, so a
+    // URI means to Skia what it means to <Image>: file, data and http, resolved
+    // the same way in both.
+    std::thread([sourceUri, op]() {
+      std::string bytes;
+      std::string error;
+      if (!fetchImageBytes(sourceUri, &bytes, &error)) {
+        LOG(WARNING) << "react-native-skia: could not read " << sourceUri << ": " << error;
+        // An empty stream, not a null one. The continuation in
+        // JsiSkDataFactory::fromURI calls `stream->getLength()` without
+        // checking, so a null here is an access violation rather than a
+        // missing image -- and a 404 on one asset would take the app down.
+        // Apple's implementation reaches the same place by accident: a failed
+        // `dataWithContentsOfURL:` leaves `data` nil, and nil's bytes and
+        // length are null and zero, so it too hands over an empty stream.
+        // Doing it deliberately keeps the two hosts on the same behaviour --
+        // the promise resolves with no bytes, the image draws as nothing, and
+        // the reason is in the log above.
+        op(SkMemoryStream::Make(SkData::MakeEmpty()));
+        return;
+      }
+      sk_sp<SkData> data = SkData::MakeWithCopy(bytes.data(), bytes.size());
+      op(SkMemoryStream::Make(std::move(data)));
+    }).detach();
+  }
+
+  // ------------------------------------------------- not implemented, and why
+
+  sk_sp<SkImage> takeScreenshotFromViewTag(size_t tag) override {
+    // Needs a tag-to-view lookup and a render of that view into a surface. The
+    // host has the first half -- the mounting manager keeps a tag registry --
+    // and nothing yet asks for the second. Named rather than blank: an empty
+    // image here would read as a broken renderer.
+    throw std::runtime_error(
+        "react-native-skia: makeImageSnapshot of a view is not implemented on this "
+        "host (tag " +
+        std::to_string(tag) + "). Render to an offscreen surface instead.");
+  }
+
+  uint64_t makeNativeBuffer(sk_sp<SkImage>) override {
+    throw std::runtime_error(unsupportedNativeBuffers());
+  }
+
+  uint64_t makeTestNativeBuffer(int, int) override {
+    throw std::runtime_error(unsupportedNativeBuffers());
+  }
+
+  void releaseNativeBuffer(uint64_t) override {
+    // Deliberately quiet: nothing here hands out a buffer, so nothing can
+    // return one, and throwing from a release path would turn a leak into a
+    // crash.
+  }
+
+ private:
+  static std::string unsupportedNativeBuffers() {
+    return "react-native-skia: native buffer interchange is not implemented on this "
+           "host. It is used for camera and video frame sharing, which nothing here "
+           "provides yet.";
+  }
+
+  static std::string unsupportedTextures() {
+    return "react-native-skia: this host has no GPU context yet, so there are no "
+           "textures to share. See win32/Win32SkiaContext.h.";
+  }
+};
+
+} // namespace
+
+std::shared_ptr<RNSkia::RNSkPlatformContext>
+makeSkiaPlatformContext(std::shared_ptr<facebook::react::CallInvoker> callInvoker) {
+  // The system DPI rather than a window's: Skia asks for one density up front,
+  // and there is no window yet when the module installs. A window dragged to a
+  // display of another scale is a thing to fix when something notices, which is
+  // the same position the AppKit half takes with NSScreen.mainScreen.
+  const UINT dpi = GetDpiForSystem();
+  const float density = dpi > 0 ? static_cast<float>(dpi) / 96.0f : 1.0f;
+  return std::make_shared<Win32SkiaPlatformContext>(std::move(callInvoker), density);
+}
+
+} // namespace basalt

package/native/win32/Win32SkiaContext.h

@@ -0,0 +1,53 @@
+// What @shopify/react-native-skia needs from this host.
+//
+// `RNSkPlatformContext` is the package's one seam: it hands Skia a runtime, a
+// call invoker and this. The package ships an Apple implementation and an
+// Android one, and neither can stand in here -- the Apple header takes an
+// `RCTBridge *`, and Android's platform context and GL canvas provider are JNI
+// all the way down. So this is basalt's, as appkit/AppKitSkiaContext.h is.
+//
+// ## Raster, for now
+//
+// AppKit's delegates to the package's `MetalContext` and has a GPU context to
+// hand out. This one has none: `getDirectContext` answers null and
+// `makeOffscreenSurface` returns a CPU surface.
+//
+// That is a deliberate first stage rather than an oversight, and it is enough
+// for the imperative API, which is what an app reaching for `Skia.Path`, image
+// decoding and typefaces uses. Reading the package's own call sites at 2.11.1:
+// `encodeToBytes` asks for the context only when an image `isTextureBacked()`,
+// which a decoded one is not; `readPixels` passes it straight to Skia, where
+// null means the CPU path; and `makeNonTextureImage` throws "No GPU context
+// available", which is the honest answer for an image that is already raster.
+//
+// `<Canvas>` is raster too, and it works: win32/Win32SkiaPeer.h renders each
+// one into a surface from `makeOffscreenSurface` and hands the pixels to the
+// Direct2D walk, because a view here is not a window and there is no layer to
+// give the package instead. What that costs is a copy per frame and a CPU
+// rasteriser; what it buys is that a canvas is clipped, scrolled and faded by
+// the views above it, and appears in the offscreen snapshot, without a line of
+// code for any of it.
+//
+// A GPU stage would be WGL or ANGLE over D3D behind `getDirectContext`, and
+// would replace the surface in that peer and nothing else. The archives are
+// already built with `skia_use_gl=true` against the day it is wanted.
+//
+// ## Fonts
+//
+// DirectWrite, through Skia's own `SkFontMgr_New_DirectWrite`, which is what
+// the Windows archives are built with -- freetype and fontconfig are off in the
+// GN args, where the Linux build has them on. The same seam, answered by
+// whatever the platform's real font system is.
+
+#pragma once
+
+#include "RNSkPlatformContext.h"
+
+#include <memory>
+
+namespace basalt {
+
+std::shared_ptr<RNSkia::RNSkPlatformContext>
+makeSkiaPlatformContext(std::shared_ptr<facebook::react::CallInvoker> callInvoker);
+
+} // namespace basalt

package/native/win32/Win32SkiaModule.cpp

@@ -0,0 +1,80 @@
+#include "Win32SkiaModule.h"
+
+#include "Win32SkiaContext.h"
+
+#include "RNSkManager.h"
+
+#include <glog/logging.h>
+
+#include <memory>
+#include <utility>
+
+namespace basalt {
+namespace {
+
+// The manager outlives the call that made it and owns everything Skia installed
+// into the runtime, so it is held here rather than on the module: a TurboModule
+// is recreated whenever the runtime is, and Skia's bindings are torn down and
+// rebuilt with it.
+//
+// Reset rather than leaked on destruction, which matters for a reload: the
+// bindings hold a jsi::Runtime reference, and keeping them past the runtime
+// they were installed into is how a reload turns into a crash in somebody
+// else's frame.
+std::unique_ptr<RNSkia::RNSkManager> &skManager() {
+  static std::unique_ptr<RNSkia::RNSkManager> manager;
+  return manager;
+}
+
+} // namespace
+
+Win32SkiaModule::Win32SkiaModule(std::shared_ptr<facebook::react::CallInvoker> jsInvoker)
+    : TurboModule(kModuleName, std::move(jsInvoker)) {
+  // Blocking and synchronous on the JavaScript thread, because the package's
+  // JavaScript calls it and then immediately expects `global.SkiaApi` to be
+  // there. Zero arity, boolean return, matching what NativeSkiaModule declares.
+  methodMap_["install"] = MethodMetadata{0, install};
+}
+
+Win32SkiaModule::~Win32SkiaModule() { skManager().reset(); }
+
+RNSkia::RNSkManager *Win32SkiaModule::manager() { return skManager().get(); }
+
+facebook::jsi::Value Win32SkiaModule::install(facebook::jsi::Runtime &runtime,
+                                              facebook::react::TurboModule &module,
+                                              const facebook::jsi::Value * /*args*/,
+                                              size_t /*count*/) {
+  if (skManager() != nullptr) {
+    // Already installed. The package calls this from module scope and React
+    // Native may evaluate that more than once; a second manager over the same
+    // runtime would install a second set of bindings over the first.
+    return facebook::jsi::Value(true);
+  }
+
+  // Through the derived type: `jsInvoker_` is protected on TurboModule, so a
+  // static member of this class may reach it on a Win32SkiaModule and not on a
+  // TurboModule. The reference is always ours -- the registry only calls this
+  // through the method table filled in above.
+  auto invoker = static_cast<Win32SkiaModule &>(module).jsInvoker_;
+  if (invoker == nullptr) {
+    LOG(ERROR) << "RNSkiaModule: no call invoker, so Skia cannot be installed";
+    return facebook::jsi::Value(false);
+  }
+
+  try {
+    skManager() = std::make_unique<RNSkia::RNSkManager>(
+        &runtime, invoker, makeSkiaPlatformContext(invoker));
+  } catch (const std::exception &error) {
+    // Reported as false rather than thrown, as on AppKit: the package's
+    // JavaScript checks the return and says something useful about it, whereas
+    // an exception crossing the JSI boundary during module initialisation
+    // arrives without a stack and without naming Skia.
+    LOG(ERROR) << "RNSkiaModule: install failed: " << error.what();
+    return facebook::jsi::Value(false);
+  }
+
+  LOG(INFO) << "RNSkiaModule: Skia installed";
+  return facebook::jsi::Value(true);
+}
+
+} // namespace basalt

package/native/win32/Win32SkiaModule.h

@@ -0,0 +1,50 @@
+// `RNSkiaModule`, the TurboModule @shopify/react-native-skia asks for by name.
+//
+// The AppKit half of this is appkit/AppKitSkiaModule.h and this is the same
+// shape, for the same reason: the package's own module is 61 lines of
+// Objective-C that builds a manager from an `RCTBridge`, and what it actually
+// needs -- a runtime, a call invoker and a platform context -- basalt already
+// has. So the module is ours and the manager is the package's.
+//
+// `install` is where Skia's whole JavaScript API arrives. Constructing
+// RNSkManager installs `SkiaApi` onto the global object, so everything the
+// package's JavaScript reaches for exists from that moment. Until it is called,
+// `getEnforcing('RNSkiaModule')` throws and an app that imports Skia does not
+// start at all -- which is exactly where kino stopped on this platform.
+//
+// In the win32 package rather than in core, for the reason Skia.cmake gives
+// about the Apple one: a platform context is a host's business.
+
+#pragma once
+
+#include <ReactCommon/TurboModule.h>
+
+#include "RNSkManager.h"
+
+#include <memory>
+
+namespace basalt {
+
+class Win32SkiaModule : public facebook::react::TurboModule {
+ public:
+  static constexpr const char *kModuleName = "RNSkiaModule";
+
+  explicit Win32SkiaModule(std::shared_ptr<facebook::react::CallInvoker> jsInvoker);
+  ~Win32SkiaModule() override;
+
+  // The manager, or null before `install` has run. A `<Canvas>` registers
+  // itself with it by nativeId -- see win32/Win32SkiaPeer.h -- and the lifetime
+  // is the runtime's rather than any one view's, which is why it is reachable
+  // here and not owned by a view.
+  static RNSkia::RNSkManager *manager();
+
+ private:
+  // A plain function, because `MethodMetadata::invoker` is a function pointer
+  // rather than a std::function -- a TurboModule's methods are static dispatch.
+  static facebook::jsi::Value install(facebook::jsi::Runtime &runtime,
+                                      facebook::react::TurboModule &module,
+                                      const facebook::jsi::Value *args,
+                                      size_t count);
+};
+
+} // namespace basalt