Commit 3678db6 added a `corner_radii: Corners<Pixels>` parameter to the
`PlatformWindow::sync_native_surface` trait method (and to the macOS impl
and the `native_surface` element call site) to clip the overlay to the
panel's rounded corners, but left the Windows, X11, and Wayland impls at
the old 2-argument signature. A 2-arg method in an `impl PlatformWindow`
block against a 3-arg trait method is an E0050 compile error, so the
workspace no longer built on Windows, X11, or Wayland — only macOS, which
is the sole CI runner, so it went unnoticed. This breaks the project's
explicit macOS/Windows/Linux requirement.
Align all three impls to the trait by accepting `_corner_radii`. Bodies
are unchanged: those platforms position/size the child surface exactly as
before and do not clip its corners (the pre-3678db6 behaviour on every
platform — not a regression; per-platform corner clipping can land later).
Verified: signatures now match the trait (`crate::Corners<Pixels>`, the
same path the trait uses), rustfmt parses all three files, and the macOS
build is unaffected (cargo check -p ely_app clean). Windows/Linux cannot
be compile-checked on this macOS host (their C deps need the platform SDK),
but the fix is a type-level signature alignment to a known trait.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The web canvas is a GPUI `native_surface` element, which on macOS
attaches an `NSView` (with a Metal-backed `CALayer`) as an AppKit
overlay on top of the GPUI render layer. GPUI's `overflow: hidden`
clips its own children but cannot reach into AppKit, so the canvas
painted square corners on top of the main panel's rounded edge —
the white surface visibly overshot the panel's rounded bottom.
Thread a per-corner radius through the GPUI patch:
- `Window::sync_native_surface` and the `PlatformWindow` trait carry
a `Corners<Pixels>`.
- The macOS implementation sets `CALayer.cornerRadius` to the maximum
requested radius and `maskedCorners` to the bitmask of corners that
actually requested rounding (GPUI is Y-down while NSView is Y-up,
so a GPUI "top" maps to a CALayer "MaxY" corner — comment locks
the mapping). `setMasksToBounds: YES` lets Core Animation actually
honor the corner radius for layered content.
- The `NativeSurface` element resolves all four corner radii from its
own `StyleRefinement` (so callers attach `.rounded_bl(...)` /
`.rounded_br(...)` exactly as on any other GPUI element).
Application side wires the right radius per context:
- The main canvas asks for `RADIUS_CARD` (18 px) on its bottom corners
so it follows the surrounding panel's rounded bottom edge while
the top stays flush against the toolbar.
- A split pane's canvas asks for the pane's own `SPLIT_PANE_RADIUS`
(10 px) so the canvas hugs the rounded frame the pane already paints.
`render_failed_web_surface` doesn't need rounding wiring — the error
page is a GPUI div and is clipped normally by the surrounding
`overflow: hidden`.
`move_traffic_light` was framing the close / minimize / zoom NSButtons
at `titlebar_height - traffic_light_position.y - button_h`. Once the
window opts into `NSFullSizeContentViewWindowMask`, the content layout
rectangle covers the whole frame and `titlebar_height()` returns 0 —
collapsing the origin to a large negative Y. macOS still painted the
buttons through its own caching layer at the title bar's natural
position, but the buttons' hit-test rectangle followed the frame off
screen, so clicking close / minimize / zoom did nothing.
Anchor the math against the close button's actual superview frame
height (the themeFrame, which equals the window height in Y-up
coordinates) so the visual position and the hit area stay in lockstep
no matter what mask combination the window opens with. `titlebar_height`
stays available for callers that want the legacy non-full-size
interpretation, with `#[allow(dead_code)]` and a docstring pointing at
this fix.
Root cause of the post-tab lag: the GPUI 16 ms timer was calling
`WebSurfaceRuntime::ensure_tab` and `tick` on the UI thread, and each
call did a synchronous `serde_json` write plus `read_line` against the
Servo sidecar over stdin/stdout. With even one visible tab, every
frame stalled on cross-process IPC.
Introduce `web_surface_worker.rs` — a per-profile worker thread that
owns the `ServoLiveClient`, drains a coalescing request queue
(latest Ensure/Poll per tab wins, no unbounded growth), and ships
results back through a `std::sync::mpsc` channel. `WebSurfaceRuntime`
now submits work non-blockingly and drains responses in `tick`; the
UI thread never blocks on the sidecar.
Adjacent in-flight cleanup riding along: hardware IOSurface
rendering-context completion (sidecar `live_protocol`,
`hardware_rendering_context`, GPUI BGRA surface shader), CSS viewport
size + device pixel ratio plumbing into `ServoLiveFrame`, and the
Send opt-ins for `CVPixelBuffer`-bearing types so frames can cross
the thread boundary.
ZacharyZhang-NYandClaude Opus 4.8