Umbrella issue for making Skyline able to host the Starling browser shell, replacing Starling's bespoke Silk.NET plumbing (Starling.Shell.Native). Starling does not reference Skyline yet.
Good news: the present path already reconciles
Starling's GpuSurfacePresenter (Starling.Paint) builds a surface-compatible wgpu device and blends layer ops straight into the swapchain texture. Skyline's GpuContext.Create(WebGPU, surfaceFactory, …) eject + the BeginClearPass = false raw path on Skyline.Render.Frame let Starling encode its blend ops into Skyline's WindowSurface.CurrentView using Skyline's device. So present is the least of the work.
One reconciliation to confirm: device/instance ownership. Today GpuBlendEngine.CreateForSurface(window) creates its own instance + device. To run on Skyline it must instead consume Skyline's GpuContext device/queue (split out a "create with an existing device" path) so there's one device and the per-layer texture cache stays resident. Surface format and present-mode come from Skyline's WindowSurface.
The port (Starling-side work, gated by the Skyline seams below)
- Replace direct Silk.NET windowing/input/GLFW-clipboard in
NativeBrowserWindow with Skyline AppWindow + FrameLoop.
- Route
GpuSurfacePresenter through Skyline's GpuContext/CurrentView.
- Move the macOS bridges (
MacImeBridge, MacAccessibilityBridge) behind the new Skyline seams.
- Note:
samples/StarlingMock.Ios is a mock (generative-shader pages), not the real engine — there's no end-to-end engine-on-Skyline proof yet.
Blockers (parity on macOS)
Cross-platform blockers
Important for browser UX
Future / polish
Already done (no work)
Window + event loop + DPI, zero-copy wgpu present with stale-swapchain recovery, FramePacer, AppHost multi-window, native macOS chrome (Skyline.Apple), clipboard text, GPU readback, interaction/approvals tier v1.
Umbrella issue for making Skyline able to host the Starling browser shell, replacing Starling's bespoke Silk.NET plumbing (
Starling.Shell.Native). Starling does not reference Skyline yet.Good news: the present path already reconciles
Starling's
GpuSurfacePresenter(Starling.Paint) builds a surface-compatible wgpu device and blends layer ops straight into the swapchain texture. Skyline'sGpuContext.Create(WebGPU, surfaceFactory, …)eject + theBeginClearPass = falseraw path onSkyline.Render.Framelet Starling encode its blend ops into Skyline'sWindowSurface.CurrentViewusing Skyline's device. So present is the least of the work.One reconciliation to confirm: device/instance ownership. Today
GpuBlendEngine.CreateForSurface(window)creates its own instance + device. To run on Skyline it must instead consume Skyline'sGpuContextdevice/queue (split out a "create with an existing device" path) so there's one device and the per-layer texture cache stays resident. Surface format and present-mode come from Skyline'sWindowSurface.The port (Starling-side work, gated by the Skyline seams below)
NativeBrowserWindowwith SkylineAppWindow+FrameLoop.GpuSurfacePresenterthrough Skyline'sGpuContext/CurrentView.MacImeBridge,MacAccessibilityBridge) behind the new Skyline seams.samples/StarlingMock.Iosis a mock (generative-shader pages), not the real engine — there's no end-to-end engine-on-Skyline proof yet.Blockers (parity on macOS)
Cross-platform blockers
Important for browser UX
Future / polish
Already done (no work)
Window + event loop + DPI, zero-copy wgpu present with stale-swapchain recovery,
FramePacer,AppHostmulti-window, native macOS chrome (Skyline.Apple), clipboard text, GPU readback, interaction/approvals tier v1.