`webview.paint()` dispatches a render command to Servo's paint thread
asynchronously, so the subsequent `read_to_image()` raced the paint
thread and reliably returned cleared-white pixels on data: URLs (T10.8).
Clear `has_pending_frame` before dispatching paint, then spin the Servo
event loop until `notify_new_frame_ready` re-arms it or 32 ms elapse
(override via `ELY_PAINT_BARRIER_MS`). Bench: software path now ships
real RGBA bytes for 60 frames instead of all-white.
Boots release ely_app, waits 8s, screencaptures full screen, verifies:
- file >10KB, dims >100x100 via sips
- center 128x128 patch not ~white (via sips crop + stdlib PNG decode)
- stderr captured to /tmp/ely-verify-stderr.log on crash
Runs idempotently (kills stale ely_app on entry + trap cleanup on exit).
No new deps; pure bash + macOS sips + /usr/bin/python3 stdlib.
First real run: PASS, screenshot /tmp/ely-verify-20260511-005449.png,
center RGB ~(243,240,236) — app chrome paints, but web surface still
shows the GPUI welcome panel (no Servo content) — exactly what T15's
paint barrier should fix.
T10.1: with the vendored `HardwareOffscreenContext` (048c5df) and the
host-level kind dispatch (a7d3e89) in place, the sidecar binary
still ignored the rendering context kind — every spawn was wired to
the software path regardless of how the host process was built. This
commit threads the choice end-to-end:
* `ely_servo_sidecar` learns a `--rendering-context [software|
hardware]` flag on its `live` subcommand. `LiveArgs` carries
the parsed `RenderingContextKind` (defaulting to `Software` so
existing invocations stay bit-identical) and `live.rs::run_live`
routes it through to `SoftwareServoHost::new_with_config_dir_and_kind`.
Unknown values produce a typed
`SidecarArgsError::InvalidRenderingContext`; a missing value
after the flag produces the existing `MissingArgumentValue`.
* `ely_app` reads `ELY_SERVO_RENDERING_CONTEXT` (with values
`software` / `hardware`, case-insensitive) and, if set, appends
`--rendering-context VALUE` to the sidecar command line.
Unset or unrecognised values fall through to the sidecar's own
software default — a stale env var or a typo never breaks the
browser startup. The sidecar arg parser is the source of truth
for legality of explicit values; the env helper only gates
which values reach it.
* Five new unit tests in `args::tests` pin the new parse paths:
default-is-software, explicit-software, explicit-hardware,
bogus-value-rejected, missing-value-rejected. Run via
`cargo test -p ely_servo_host --features servo-engine --bin
ely_servo_sidecar` and now hit alongside the five existing
snapshot tests for 10 passes.
End-to-end perf expectation: with the sidecar binary built using
`--features servo-engine,hardware-render` and the env var set to
`hardware`, every spawned sidecar webview rasterises through the
real GPU adapter (via the vendored
`HardwareOffscreenContext`/surfman/CGL chain on macOS). The host
still reads back RGBA into a `Vec<u8>` for the existing pipe
protocol; the IOSurface zero-copy bridge that deletes that
read-back is T10.2–T10.5 in docs/t10-iosurface-plan.md and lands
in subsequent commits.
cargo test --bin ely_app: 120 passed, 0 failed, 2 ignored.
cargo test -p ely_servo_host --features servo-engine --bin ely_servo_sidecar: 10 passed.
cargo test -p ely_servo_host --features servo-engine --test sidecar: 9 passed.
cargo test -p ely_servo_host --features servo-engine,hardware-render --test hardware_rendering_context: 1 passed.
`HardwareOffscreenContext` was vendored in 048c5df but the host's
per-webview `new_rendering_context` still hard-wired
`servo::SoftwareRenderingContext`. This commit threads a
`RenderingContextKind` enum through the host so existing call sites
keep their software path, and new callers can opt into the hardware
path through `SoftwareServoHost::new_with_config_dir_and_kind(...)`.
Three changes, kept tightly scoped:
* `runtime.rs` gains a public `RenderingContextKind { Software,
Hardware }` enum and a new constructor that takes it. The
existing `new` and `new_with_config_dir` keep their signatures
and default to `Software`, so the sidecar binary and the
integration tests pick up zero behavioural change. The
private `new_rendering_context` moves from a free function to a
`&self` method so it can read `self.rendering_context_kind` and
dispatch — `Software` constructs `SoftwareRenderingContext` as
before, `Hardware` constructs the vendored
`HardwareOffscreenContext`. When the `hardware-render` feature
isn't compiled in, the `Hardware` arm returns
`ServoHostError::HardwareRenderUnavailable` instead of silently
falling back; the new constructor also rejects the request
up-front before touching the global Servo runtime flag.
* `error.rs` gains `HardwareRenderUnavailable` so the wrong-feature
path is a typed error, not a panic.
* `lib.rs` exports `RenderingContextKind` alongside
`SoftwareServoHost` so downstream code (next commit will be the
sidecar's `--rendering-context` CLI flag and the live.rs
plumbing) can name the variant directly.
This is purely an extension point — no existing call path changes,
no existing test asserts on the new enum. The next commit will add
the sidecar CLI flag and wire `live.rs::run_live` to pass the kind
through to the host so users can pick the path at startup. The
follow-up commits then extract the IOSurface from the hardware
surfman surface and bridge it across the IPC channel to GPUI's
Metal renderer, deleting the host-side `Vec<u8>` from the per-frame
hot path entirely (full plan in docs/t10-iosurface-plan.md).
cargo test -p ely_servo_host --features servo-engine --lib: 2 passed.
cargo test -p ely_servo_host --features servo-engine --test sidecar: 9 passed.
cargo test -p ely_servo_host --features servo-engine,hardware-render
--test hardware_rendering_context: 1 passed.
cargo test --bin ely_app: 120 passed, 0 failed, 2 ignored.
The first concrete step toward the T10 IOSurface zero-copy path
(plan in docs/t10-iosurface-plan.md). Before this commit the sidecar
process could only use `SoftwareRenderingContext` — CPU rasterising
plus an 8 MB RGBA readback per 1080p frame is most of where scroll
latency comes from after the file pipe (a80d039), Vec clone
(e02c0fd), texture dedup (7f3b8b4), and hash swap (3f184ee) have
all landed.
The blocker is purely architectural: `servo-paint-api 0.1` exposes
`OffscreenRenderingContext` only as a child of
`WindowRenderingContext`, which requires a `DisplayHandle +
WindowHandle`. The sidecar has no window. The underlying
`SurfmanRenderingContext` glue *can* drive a hardware adapter
against a `SurfaceType::Generic` offscreen surface, but its
constructor is private. Until the upstream PR lands, this commit
vendors the minimal slice of that glue into `ely_servo_host`:
* `HardwareOffscreenContext::new(size)` uses
`Connection::new() → create_adapter()` (real GPU, not the
software adapter) and a `SurfaceType::Generic` offscreen
surface. On macOS the surfman CGL backend backs that surface
with an `IOSurface` — exactly the thing the IOSurface bridge
in subsequent commits will reach for.
* Implements `servo::RenderingContext` so it slots into
`ServoBuilder::rendering_context` wherever the existing
`SoftwareRenderingContext` does, with no other Servo-side
knowledge.
* Scope deliberately narrow: only the methods Servo's headless
readback actually calls. `create_texture` /
`destroy_texture` / `connection` / `refresh_driver` fall
through to the trait's `None` defaults. `read_to_image` inlines
the upstream `Framebuffer::read_framebuffer_to_image` helper so
we don't reach for a private helper that may change shape.
* No `RawWindowHandle` and no `RefreshDriver` — both belong to
paths the headless sidecar doesn't take.
The whole thing is feature-gated on `hardware-render`. Default
builds compile zero new lines; the additional surfman / gleam /
glow / euclid / image / log deps are all `optional = true`. Sidecar
binary still uses `SoftwareServoHost` until a follow-up commit
threads the new context in behind a CLI flag.
A smoke test at `tests/hardware_rendering_context.rs` constructs
the context. On a host with a real GPU it returns `Ok`; on a no-GPU
CI host it logs the surfman cause and reports `ok` rather than
failing the suite — the test is guarding the wiring, not the
hardware availability. On this Mac it constructs cleanly.
The `expect_used` / `unwrap_used` workspace lints are honoured —
fallible reads return `None` instead of panicking, no `.expect()` /
`.unwrap()` survives in the vendored body. The two `unsafe` blocks
(loading GL function pointers via surfman's `get_proc_address`) are
the same blocks upstream uses, with `#[expect(unsafe_code)]` to
override the workspace `unsafe_code = "deny"` lint locally.
cargo test --bin ely_app: 120 passed.
cargo test -p ely_servo_host --features servo-engine,hardware-render
--test hardware_rendering_context: 1 passed (constructs cleanly).
Pre-existing `manages_real_servo_webview_lifecycle` failure on
servo.org is unrelated (reproduces on b8795bf without this change,
already documented in T7's commit history).
Two T10-flavoured changes in one commit, each independently ship-able
on its own:
1. `web_surface_frame::rgba_hash` switches from std's
`DefaultHasher` (SipHash13, ~1.5 GB/s) to `ahash::AHasher`
(~10 GB/s). At 1080p (8 MB per frame) the dedup key drops from
~5 ms to ~0.8 ms per cache-miss frame, returning roughly 25 % of
the 16 ms scroll budget that was being spent hashing the
newly-arrived RGBA payload. ahash was already in the dependency
graph transitively via hashbrown, so this only adds a direct
`ahash = "0.8"` line and one Cargo.lock entry.
2. `docs/t10-iosurface-plan.md` records the full architectural
roadmap for the actual zero-copy path that supersedes the
software-pipe pipeline: `OffscreenRenderingContext` against a
hardware surfman adapter, IOSurface-backed surface on macOS,
mach-port handoff to the GPUI process, MTLTexture import as an
external sampler. The document explains why each currently
shipped commit (`840255f`, `a80d039`, `e02c0fd`, `7f3b8b4`, plus
this hash swap) is a stepping stone that eventually deletes
itself once the IOSurface path lands, and names the upstream
API gap in `servo-paint-api` that blocks step 2.
cargo test --bin ely_app: 120 passed, 0 failed, 2 ignored.
Hash collision probability remains ~1 in 2^64; AHash uses the same
keyspace as the previous SipHash13.
Three new diagnostics narrow T7 to test-mode infrastructure:
1. `diagnose_t7_hitbox_reachability_heatmap` (ignored, --nocapture):
builds the real ElyShell, navigates to https://example.com/, then
sweeps a 6×6 grid across the full 1920×1080 window dispatching
mouse_move at each cell and recording hover_point. Result: **0 of
36 grid cells trigger hover_point** — input_overlay's listener
misses every position in the window, not just the viewport center.
2. Same test then dispatches a single MouseDown at the viewport
center and reads back `focus_handle.is_focused`. Result: **true**.
The root div's `track_focus` MouseDown bubble handler fires on
the very same event. GPUI dispatch IS working at the root hitbox
(`.size_full()`).
3. `baseline_overlay_after_gpui_component_init_receives_click` and
`baseline_overlay_with_input_state_construction_receives_click`:
replicate `gpui_component::init` and `InputState::new` +
`subscribe_in` in isolation. Both still pass — neither breaks
hit_test for an occlude div.
Together these isolate the failure to *something `ElyShell::new`
configures that interacts badly with `TestAppContext`'s simulated
executor*, after every individual ingredient passes. The user has
already confirmed (in the previous round) that "click works" after
the layout fix in 840255f lands in the real binary; the T7 red
guard is reproducing a test-mode quirk, not a production regression.
The red guard stays in the suite as documentation. Its `#[ignore]`
reason now records the diagnostic outcome so the next reader doesn't
re-walk the same bisect. Two paths forward (recorded in the
attribute):
(a) reproduce the bug outside TestAppContext and file upstream
(b) route web canvas input through the root div + a viewport-bounds
gate, which sidesteps hit_test for input_overlay entirely
(b) is structurally more complex than it looks because backdrops
(workspace disclosure, hidden-sidebar overlay) sit in z-order in
front of input_overlay and don't `stop_propagation` — implementing
a clean root-level fallback requires teasing apart the cases. Not
done in this commit.
cargo test --bin ely_app: 120 passed, 0 failed, 2 ignored.
cargo test --bin ely_app -- --ignored: 1 fail (T7 red) + 1 pass
(diagnostic, which just prints the heatmap and reports findings).
`LiveOutcome::frame` was carrying the rendered bytes as a fresh
`Vec<u8>` cloned out of `RenderedFrame::rgba_bytes()`. At 60 fps
on a 1080p canvas that was an extra 8 MB allocation + memcpy per
frame on top of the clone `host.last_rendered_frame()` already
paid for. `LiveOutcome` now carries the owned `RenderedFrame`
directly, and `write_outcome` writes its `rgba_bytes()` slice
straight to stdout — same single-clone cost as the host already
incurred, no second allocation.
Small Karpathy-style follow-up from the T8 review ("the host
still copies its rendered buffer to a transient Vec<u8> before
write_all; expose &[u8] straight to write_all once the profile
shows that allocation in the top five"). Profile data is still
deferred (T9 was marked vibe-benchmarking until T10 lands a real
spec), but removing the cheap clone is structurally cleaner and
makes the dispatch path one allocation lighter regardless.
cargo test --bin ely_app: 118 passed, 0 failed, 1 ignored.
cargo test -p ely_servo_host --features servo-engine --test sidecar: 9 passed.
T13 (the still-red `user_click_in_rendered_web_canvas_reaches_input_pipeline`
guard) is now backed by five bisect probes that each reproduce one
slice of the real ElyShell render tree and assert the listener combo
still receives a simulated click. Every probe passes:
* baseline_overlay_div_receives_simulated_click — GPUI primitives
* baseline_overlay_with_full_listener_combo_receives_click — exact
listener combo (on_mouse_down + capture_any_mouse_up +
on_mouse_move + on_scroll_wheel) on a single .occlude() div
* baseline_overlay_under_overflow_hidden_relative_receives_click —
the relative + overflow_hidden wrapper render_web_surface uses
* baseline_overlay_under_full_elyshell_wrapper_chain_receives_click —
root → absolute-flex container → main-pane → content-wrapper
→ surface-wrapper chain
* baseline_overlay_with_canvas_sibling_receives_click — adds the
canvas viewport_tracker sibling
* baseline_overlay_with_entity_update_in_mouse_down_receives_click —
on_mouse_down's bubble fires entity.update (auto-notify) before
MouseUp dispatches
* baseline_overlay_under_root_with_track_focus_receives_click —
the full chain wrapped in a root div with track_focus +
on_mouse_up(Left, bubble)
The red guard meanwhile reports `hover_point = None` after
`simulate_mouse_move`, meaning input_overlay's `on_mouse_move`
also never fires — so the failure mode isn't capture-specific.
ALL of the overlay's listeners share the same `hitbox.is_hovered`
check, and it returns false in the real ElyShell tree but true in
every probe. Whatever the difference is, it is in
`ElyShell::new`'s setup (BrowserCore, Entity<InputState>,
SliderState, subscriptions, `start_external_web_surface_timer`'s
detached task) or in the `sync_address_input` call that
`navigate_active_tab` runs through Input's `set_value` — none of
which the probes touch.
The probes stay in the suite as both documentation (they encode
what is *not* the bug, narrowing the search for the next round)
and as regression guards (a future change that breaks them is a
real new regression in plain layout, not in the still-elusive
ElyShell-specific bug). Tests run as 118 passed + 1 ignored;
`cargo test -- --ignored` continues to fail with the same T7 red
guard. T13 is intentionally still in progress.
WebSurfaceFrame::from_parts was unconditionally calling
Arc::new(RenderImage::new([image::Frame::new(image_buffer)])) on
every live frame, even when the underlying bytes were
byte-for-byte identical to the previous frame. At 60 fps on a 1080p
canvas that was ~960 MB/s of host-side cloning plus a fresh GPUI
texture allocation on every tick — the bottleneck Linus + Karpathy
+ Jony flagged as the next material step after dropping the
file-system pixel pipe (a80d039).
A thread_local single-slot cache in web_surface_frame.rs now keys
on a 64-bit DefaultHasher of the raw RGBA bytes. On a cache hit
the existing Arc<RenderImage> is reused; on a miss the buffer is
built once, stored, and returned. Steady-state idle pages stop
churning the GPUI texture pool entirely. Hash collisions are
1 in 2^64 — if that ever becomes a real worry, the cache key can
be widened to length + a sample of bytes before paying the full
memcmp; not worth doing today.
The T10 red guard
(identical_live_frames_share_render_image_arc) drops its
#[ignore] attribute outright per the contract it documented.
The T7 red guard (user_click_in_rendered_web_canvas_reaches_input_pipeline)
remains ignored — it's a separate diagnosis tracked under T13.
cargo test --bin ely_app: 113 passed, 0 failed, 1 ignored
(was 112+2, T10 guard went green).
cargo test --bin ely_app -- --ignored: 1 failed (only T7 click
pipeline remains red).
Follow-ups (left for the endgame T10 IOSurface path):
* a per-tab cache would prevent multi-tab switching from
thrashing the single slot; defer until a real multi-tab
scroll benchmark shows it matters.
* the endgame is OffscreenRenderingContext + IOSurface so the
GPU texture itself is the source of truth and the host-side
Vec<u8> + ImageBuffer + RenderImage allocation chain
disappears entirely.
Every `WebSurfaceFrame::from_live_frame` today calls
`Arc::new(RenderImage::new([image::Frame::new(image_buffer)]))`
unconditionally — even when the underlying RGBA bytes are
byte-for-byte identical to the previous frame. At 60 fps on a 1080p
canvas that is roughly 960 MB/s of host-side cloning + a fresh
GPUI texture upload, and the roundtable agreed it is the next
material bottleneck after the file-system pipe (a80d039).
The contract this test pins is the cheapest invariant we can hold
against today's `SoftwareRenderingContext`: two `ServoLiveFrame`
inputs whose `rgba_bytes` are bit-identical must produce the same
underlying `Arc<RenderImage>` instance. Today they do not; the
ignored run confirms two distinct pointer values for back-to-back
identical inputs.
The fix has two recognised shapes. The interim shape lives entirely
in `WebSurfaceFrame::from_parts`: remember the previous frame's
bytes (hash or pointer-eq) and reuse the existing `Arc<RenderImage>`
when they match. The endgame shape removes the host-side image step
entirely — `OffscreenRenderingContext` + IOSurface — at which point
the assertion becomes meaningless and is replaced by a frame-time
budget. Whichever lands first, the fix commit MUST delete the
`#[ignore]` attribute outright; toggling its reason is a broken
contract.
To call `WebSurfaceFrame::from_live_frame` from a unit test without
spawning a real sidecar process, `ServoLiveFrame` gains a
`#[cfg(test)] pub(crate) fn for_test(...)` constructor that wraps
the existing private `from_parts` with realistic defaults. No
production path uses it.
cargo test --bin ely_app: 112 passed, 0 failed, 2 ignored.
cargo test --bin ely_app -- --ignored: 2 failed (expected RED:
T7 click pipeline + T10 texture re-upload).
After 840255f put the input overlay on-screen and a80d039 dropped
the file-system pixel pipe, the two harness baselines confirm:
* `.occlude() + capture_any_mouse_up` works in TestAppContext
(baseline_overlay_div_receives_simulated_click)
* `input_overlay`'s exact listener combo works in isolation
(baseline_overlay_with_full_listener_combo_receives_click)
…and the layout regression guard confirms the overlay is now drawn
inside the visible window. Yet running a real ElyShell, navigating
to https://example.com/, and dispatching a real MouseDown/MouseUp at
the geometric center of the measured viewport STILL leaves
WebSurfaceStore.click_point as None. The capture phase listener is
being eaten somewhere strictly inside the real ElyShell widget tree.
`user_click_in_rendered_web_canvas_reaches_input_pipeline` encodes
this contract in user terms — "click on the rendered page and the
input pipeline records it" — without naming a GPUI mechanism. The
test is marked `#[ignore]` so the rest of the suite stays green; the
attribute carries the full reproduction note so a reader picking the
ticket up later doesn't have to rediscover what we already know
(layout + pixel-pipe both clean, listener combo clean, suspicion now
on sibling z-order / ancestor stop_propagation / overflow_hidden
content_mask clipping the overlay's hitbox).
The fix commit must DELETE the attribute outright; toggling the
ignore reason is a broken contract. Running
`cargo test -- --ignored user_click_in_rendered_web_canvas_reaches_input_pipeline`
today reproduces the failure with click_at = (1106, 567) inside
viewport_bounds (309, 71, 1594, 992).
cargo test --bin ely_app: 112 passed, 0 failed, 1 ignored.
cargo test --bin ely_app -- --ignored: 1 failed (expected RED).
ZacharyZhang-NY