Repository navigation
Conversation
This was referenced Sep 27, 2026
Closed
Switch the mobile platform and the example from Zed git dependencies to the matching `gpui-pre` / `gpui-pre-wgpu` 0.3.4 crates.io packages (imported as `gpui` / `gpui_wgpu`, so no `use` changes are needed). This removes the `[patch.crates-io]` async-task fork and every git dependency, which makes the crate publishable to crates.io and lets consumers depend on it without reproducing Zed's patches. Adapt to the platform and styling API differences, fix the "wpgu" typo in the crate description, and update the publish workflow to check the iOS backends before publishing and to treat the `dry-run` input as the boolean it is. Test plan: - cargo check --all-targets - cargo check --target aarch64-apple-ios / aarch64-apple-ios-sim - cargo test --lib
Embed GPUI Kit's Markdown TextView in a Swift-owned UIKit window instead of letting GPUI create the iOS example's window. A child controller renders into `GPUITextView: UIView`; native Compact / Expanded controls exercise layout changes. The light English sample puts emphasis, quotes, nested lists, code, tables, and tasks on the first screen. Fix two startup failures exposed by the simulator: supply the UIKit display handle to wgpu 29, and retain the `run_embedded` application handle so native callbacks cannot outlive the GPUI app. Synchronize layout and redraw without implicit animations during size changes. Correct the Xcode static-library paths and build directory. Pins GPUI Kit to commit `7d9efcd2069f9eaa6eb3ba6345aac4aa7d87c9f7` from longbridge/gpui-kit#3045, so a sibling local checkout is not required. No crates are published. The embedding example supports one GPUI view for the application lifetime; independent destruction and multiple instances are not implemented. - Passed `cargo check --manifest-path example/Cargo.toml --target aarch64-apple-ios-sim` with the pinned Git dependency. - Built the Swift app with Xcode for the iOS simulator and ran it on iPhone 17 Pro / iOS 26.5 using the same GPUI Kit source revision locally. - Verified light Markdown rendering, native controls, and Compact / Expanded resizing. - Passed `git diff --check` and `bash -n example/build.sh`. - Embedded scrolling needs manual verification: the automation tool emitted touch begin/end without move events. Transient resize jitter also needs visual confirmation. - No Android, physical-device, or performance testing performed. --------- Co-authored-by: Codex <codex@openai.com>
A released iOS touch currently leaves GPUI's synthetic mouse over the last control, keeping hover feedback active. Clear the pointer hit test and emit MouseExited after touch end/cancellation and momentum frames, while preserving the original position for click and scroll dispatch. Handle UIKit cancellation separately so it never commits a deferred tap or starts a momentum fling. Cancel an active scroll with TouchPhase::Cancelled. Update the example's GPUI Kit revision to include mobile tooltip suppression, tap-triggered HoverCard behavior, and the inline is_mobile helper from longbridge/gpui-kit#3045. - Built the Swift-hosted iOS example for aarch64-apple-ios-sim. - Used a temporary simulator smoke view to check HoverCard opens on tap, remains open when its content is tapped, and closes on outside tap. - Checked a normal ghost button with a configured tooltip: no lingering hover background or tooltip after release. - Restored the original chat example and rebuilt it with the final Kit revision. - GPUI Kit regression tests cover desktop hover and mobile tap interaction. - UIKit cancellation was reviewed in code; no system-cancellation gesture was injected. Android was not changed or tested. No crates published. Co-authored-by: Codex <codex@openai.com>
## Summary Apply the iOS touch cleanup from #3 to Android. After touch release/cancellation and every momentum frame, move the synthetic pointer outside the window and emit MouseExited so hover does not remain on the last control. Preserve original coordinates for click and scroll dispatch. Handle ACTION_CANCEL independently: discard queued coalesced scroll, reset velocity, stop inertia, and emit ScrollWheel(Cancelled) for an active scroll. Never turn cancellation into a tap or fling, and ignore stray moves with no active touch. Add regression tests and update an existing test to use the renamed gpu_specs API. ## Test Plan - Android arm64/API 31 cargo-ndk library check passed. - Built the Android unit-test executable and ran touch tests on an Android API 34 arm64 emulator: 5 passed. - Tests cover tap coordinates, pending-tap cancellation, coalesced-scroll cancellation, and post-momentum hover cleanup. - This verification covers platform event dispatch; Android app UI testing is ongoing separately. Co-authored-by: Codex <codex@openai.com>
iOS and Android Chinese keyboards could not reliably compose text, Add files returned an error or no result, and converting every drag to scroll prevented controls from claiming touch gestures. - Use a native UITextView composition buffer to provide UITextInput support and forward plain and attributed marked text, UTF-16 selection, commits, and deletion to GPUI. - Present an asynchronous UIDocumentPicker, returning sandbox copies of selected files (including images in Files), with multi-selection and cancellation support. - Forward UIKit contacts as GPUI TouchEvents with stable IDs. GPUI's existing recognizer handles taps, long presses, control drags, scrolling, and inertia, replacing the duplicate iOS mouse/scroll synthesis. - Add an Android InputConnection bridge with native-thread composition delivery, UTF-16 selection, Unicode-safe deletion, and session checks for stale callbacks. Keep legacy TextInput commit/backspace callbacks working. Custom hosts use GpuiInputActivity; the example inherits it. - Connect Android file prompts to SAF and copy content URIs into app cache on a worker before returning readable paths. Register the picker Activity in the example. - Forward Android contacts as TouchEvents, preserve multiple pointer identities, and distinguish cancellation from release. Remove duplicate mouse/momentum synthesis, desktop Fontconfig loading on Android, and unconditional frame presentation (matching the existing ai-chat host workarounds). - Fix two simulator Debug crashes: UIKit dynamically forwards public keyboard trait setters, and NSString byte initializers require `const void *` rather than byte-pointer encoding. Correct the matching URL/maps initializer calls too. This uses existing GPUI 0.3.4 APIs; no GPUI core changes. TextView selection and scrollbar thumb dragging also require the companion gpui-kit handlers. The file pickers accept images accessible through Files/Documents; they do not add a separate Photos library entry point. Touch-driven focus changes finish the current composition before dispatch. On iOS, programmatic focus switches without a touch or keyboard hide still need a platform focus identity signal; clearing the previous GPUI field's marked state on programmatic blur remains a follow-up. - Passed: `cargo check --target aarch64-apple-ios --lib --offline --no-default-features --features camera,video_player`. - Passed: `cargo check --target aarch64-apple-ios-sim --lib --offline --no-default-features --features camera,video_player`. - Passed: Android backend library/test cross-compilation with NDK 27, and the complete ai-chat Android host's `cargo ndk -t arm64-v8a --platform 26 check --locked --offline` using these local changes. - Passed: Android API 34 Java compilation, including the host's `:app:compileDebugJavaWithJavac` task. - Passed: 2 host-run regression tests for the actual Unicode deletion and legacy callback helpers; Android touch regression tests compile but were not run on a device. - Passed: Rust formatting and `git diff --check`. - Passed on iOS 26.5 simulator Debug: input focus and English input; software Pinyin `ni` followed by selecting `你` inserts Chinese into the GPUI input; explicit keyboard dismissal; Files picker opens and cancels twice without crashing or reopening the keyboard. - Passed: native objc2 Debug probe reproduces the old NSString signature rejection and verifies corrected English, Chinese/emoji, Chinese URL and empty-string roundtrips. Keyboard-trait forwarding was also checked against this UIKit runtime. - Passed: attributed-marked-text runtime probe reaches the override once, preserves ni composition and UTF-16 selection, then commits Chinese. Requester confirmed Chinese input and subsequent iOS/Android device testing complete. - Passed: full ai-chat Android Debug and optimized Release builds, installation and startup on Samsung Android 12 ARM64; Release package verified non-debuggable. - Not addressed by a dedicated fix: the reported held-key repeat case (discrete 256 insert/delete callbacks pass), or the separately identified insertText:alternatives:style: entry point. No system autorepeat validation is claimed by those discrete-callback tests. --------- Co-authored-by: Codex <codex@openai.com>
## Description The iOS window implemented neither `PlatformWindow::frame_waker` nor `schedule_frame`, so a host had to tick GPUI on every vsync and let it discover there was nothing to draw — ~2% of a core at 60 Hz (4% at 120 Hz) on an idle screen. `IosWindow` now carries a `FrameDemand` (new platform-neutral module, unit-tested) shared with the FFI layer: - `frame_waker` / `schedule_frame` raise demand and call a host-registered waker on the first demand since the last tick. - `gpui_ios_request_frame` clears demand before the frame and returns whether GPUI wants another (demand re-raised mid-frame, or text input waiting). - New `gpui_ios_set_frame_waker(window, waker, context)` registers the host callback. - Software-keyboard text and keyboard-height changes go through `mark_text_input_dirty()`, which also wakes every window. A host pauses its `CADisplayLink` when `gpui_ios_request_frame` returns `false` and resumes it from the waker (`example/ios/main.m`). Hosts that tick unconditionally keep working. Measured on the Longbridge AI chat (iPhone 17 Pro simulator, Release): idle CPU 2% → 0.0%; scrolling, fling, focus and caret unchanged. ## Breaking Changes - `gpui_ios_request_frame` now returns `bool` instead of `void`. Update the header your host compiles against; Swift callers must consume the result. ```diff - void gpui_ios_request_frame(void *window_ptr); + bool gpui_ios_request_frame(void *window_ptr); ``` ```diff - gpui_ios_request_frame(window) + _ = gpui_ios_request_frame(window) ``` 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Codex <codex@openai.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Description Holding Backspace on the iOS software keyboard deleted exactly one character; Android keeps deleting while the key is held. UIKit drives the repeat from a timer, `-[_UIKeyboardStateManager handleAutoDeleteWithExecutionContext:]`, which asks the first responder `_selectionAtDocumentStart` before every repeat and calls `_stopAutoDeleteAtDocumentStart` (releases the key, clears the timer) the moment the answer is YES. `-[UIResponder(UITextInput_Internal) _selectionAtDocumentStart]` compares `selectedTextRange.start` with `beginningOfDocument`. `GPUITextInputView` is a `UITextView` whose document only holds the current composition and is empty between keystrokes, so the caret always sat at the document start and the timer gave up after the first delete. The existing `hasText` → YES override does not help: UIKit only consults `hasText` for the first delete (`canHandleDelete` → `noContent`), never for the repeat. (All of the above verified by disassembling UIKitCore from the iOS 26.5 simulator runtime.) The fix overrides `_selectionAtDocumentStart` on `GPUITextInputView` to answer for the GPUI document whenever the scratch document has nothing UIKit could delete natively: - with a `PlatformInputHandler` installed (gpui-component `Input`), `selected_text_range().range.start == 0` decides, so the repeat still stops once the field is empty; - with only a legacy `set_text_input_callback` (which cannot report its content) the repeat keeps going; each extra Backspace on an empty field is a no-op there; - while a composition lives in the native view (marked text or non-empty scratch document) `UITextView`'s own answer stands, so IME behaviour is unchanged. The selector is private UIKit; `objc2`'s `sel!` registers it at runtime from a plain C string, so it does not appear in `__objc_selrefs`. Hardware keyboards are not affected either way: their repeats arrive as key events that go through `handleDeleteAsRepeat:` directly, without the timer. ## How to Test 1. Build the example (or any consumer) for a device or simulator with the software keyboard shown (Simulator: I/O › Keyboard › Toggle Software Keyboard, ⌘K). 2. Focus a text input, type a few words, then press and hold the keyboard's Backspace key. 3. Before: one character is removed and the key releases. After: characters keep deleting while held (UIKit switches to faster deletion after ~20 repeats), and the repeat stops once the field is empty. 4. Type with a Chinese/Japanese IME and delete inside the composition: unchanged. Checks run: `cargo check --target aarch64-apple-ios-sim --no-default-features --features camera,video_player`, `cargo check --target aarch64-apple-ios`, `cargo check --all-targets`, `cargo fmt --all -- --check`, clippy on the iOS target; the ai-chat iOS example built against this branch launches on the iOS 26.5 simulator. The held-key behaviour itself still needs a device (the simulator here is headless, so no touch could be injected). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01HY6KNBpkTcKkW2PpjrFhji Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary Recreating an Activity in-process left a black screen: `android_main` runs each Activity on a fresh native thread, but `AndroidDispatcher` had captured the old thread's `ALooper`, so `App::new_app` hit `assert!(is_main_thread())`. This adds `android::host`, an additive entry point where the host owns a plain `Activity` + `SurfaceView` and GPUI runs on one process-lived render thread. `host::start(|cx| ..)` builds the app with `run_embedded` and keeps it alive; the host registers each Activity with `jni::set_host_activity`, hands surfaces over via `surface_created` / `surface_destroyed`, and forwards input through `motion_event` / `key` / `ime_event`. The `android-activity` path is untouched. `window.rs` fixes needed to keep one `App` across surfaces: force a full repaint after a surface swap, notify GPUI when a re-attached surface has a new size, and rebuild the surface in place when the same `ANativeWindow` comes back. Tested on Huawei P40 and an API 35 emulator: 40+ recreations, no black screen. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: 涂阳川 <yangchuan.tu@longbridge-inc.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Jason Lee <huacnlee@gmail.com>
## Description Both Android loops (`jni::run_event_loop` over android-activity and the `host` render thread) ticked GPUI on every iteration and paced themselves with a 500 µs / 8 ms sleep, leaving the frame rate to the swapchain. With `Mailbox` presentation a scrolling window was drawn as fast as the CPU could lay it out, most of those frames were dropped by the compositor, and an idle window still woke up 2000 times a second. This is the Android counterpart of #8. The loops now draw only when GPUI asked for a frame **and** a vsync has passed since: - **`frame_pacer`** (platform-neutral, unit-tested) folds demand into one pending frame: the first demand since the last frame posts a vsync callback, the callback marks a frame due, the loop draws it once. Demand that arrives an interval or more after the last frame began (the loop is behind, or was idle) is due at once — waiting for the next vsync there only delays the frame and the input batched behind it, and GPUI stamps touches at dispatch time (a gap over 40 ms between samples kills a fling). - **`android::frame_source`** runs `AChoreographer` on its own `gpui-vsync` thread and wakes the loop's `ALooper` on each frame callback. It cannot live on the loop's looper: android-activity logs every looper source it did not register as `Spurious ALOOPER_POLL_CALLBACK`, once per delivery (60 lines/s while scrolling). - `AndroidPlatformWindow` implements `frame_waker` / `schedule_frame`; a surface swap and a resume re-post the callback (one posted before the app went to the background may never fire); software-keyboard text wakes the loop from the UI thread. - The loops block on the looper between events. `AndroidDispatcher` exposes the next delayed task's due time and wakes the looper when a delayed task is posted, so GPUI timers keep firing without a spin. A 1 s cap bounds any missed wakeup. Hosts need no changes: both entry points install the pacer themselves. ## Measurements API 34 emulator (lavapipe), gpui-mobile example, Release Rust: | | main | this PR | |---|---|---| | idle CPU | spin (500 µs sleep) | 0.0 %, 5 loop iterations / 5 s | | backgrounded | spin | asleep (heartbeat every 1 s) | | scripted swipe → fling | 0 / 8 | 4 / 8 | | `Spurious ALOOPER_POLL_CALLBACK` while scrolling | – | none from frames (only the pre-existing dispatcher pipe ones) | The fling row is the emulator's 40 ms frames sitting on GPUI's 40 ms stopped-gap threshold either way; a phone with ≤ 16 ms frames is not affected. The real test is the Huawei P40 that showed the scroll jank this is for — please measure there before merging. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Problem When the keyboard appears (or on any other UIKit-animated bounds change — split view, rotation), the whole GPUI view visibly deforms for the length of the animation: text and controls grow ~15 % taller frame by frame, then snap back. UIKit animates the view's bounds, but `viewDidLayoutSubviews` reports only the final size, so `handle_layout_change` reconfigures the drawable and GPUI renders at the final size immediately, while Core Animation is still interpolating the presented bounds. The `CAMetalLayer`'s default `contentsGravity` is `resize`, which stretches that last drawable to every intermediate size. ## Fix Set the layer's `contentsGravity` to `kCAGravityBottomLeft` when the Metal view is created — Core Animation's y-up name for the visual top-left of a UIKit view (`kCAGravityTopLeft` pins to the visual bottom, verified). The drawable keeps its true scale pinned to the top-left; the strip the animation has not reached yet stays blank behind the keyboard. ## Verification iPhone 17 Pro simulator, Longbridge AI chat, screen recording of the keyboard-show animation frame by frame: before — the content stretched over ~10 frames; after — no deformation, the composer moves straight to its final position and the keyboard slides up under it. `cargo check --target aarch64-apple-ios-sim` clean. Follow-up (not in this PR): to have the composer glide with the keyboard instead of jumping, the host would lay GPUI out at the layer's presentation bounds on each display-link tick during the animation. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
…Source Two gaps a host app hits on the `android::host` path. Both are Android-only: everything here lives under `src/android/`, which `lib.rs` gates behind `#[cfg(target_os = "android")]`, so iOS does not compile it. Verified by building the crate for `aarch64-apple-ios` with these changes applied. ## Flings used iOS physics `AndroidPlatform` never implemented `Platform::gestures`, so GPUI fell back to `GestureTuning::default()` — whose `scroll_physics` is `UIScrollView`'s exponential decay. Every Android app built on gpui-mobile has therefore been flinging with iOS physics: the content coasts much further than the platform's own scroll views, which reads as the list not stopping where you expect. This returns `ScrollPhysics::android()` instead, the AOSP `OverScroller` friction spline that already lives in `gestures.rs`. GPUI flings in logical pixels and a window's scale factor is Android's display density, so logical pixels are density-independent pixels and the constructor's nominal 160 dpi pairing is the right one. Measured on a Huawei P40 (1080x2340 @3x), same conversation and gesture script, counting frames for 2.5s after release: | fling | iOS physics | Android physics | |---|---|---| | swipe 80ms | 71 frames | 58 frames | | swipe 300ms | 60 frames | 41 frames | Fewer frames because the spline sheds speed faster and the fling travels a shorter distance — the point of the change, not a regression. Frame pacing is unchanged: 16ms intervals throughout, `droppedFrames = 0` in both. The rest of `ViewConfiguration` (touch slop, tap timeouts) stays on GPUI's defaults; reading the real values over JNI is a separate change. ## A host could not install an asset source `host::start` hands the launch closure a `&mut App`, which is one step too late to install an asset source: `Application::with_assets` consumes the builder, and the builder is created inside `on_surface_created` where the host cannot reach it. The failure is silent. `AssetSource::load` returning `None` is a valid answer, so nothing logs and anything resolved through the asset source — icons, SVGs — simply does not appear. `start_with_assets` stores the configuration step in a static that `on_surface_created` consumes when it builds the `Application`, right before `run_embedded`. `start` keeps its current shape for hosts that do not need one. ## Testing - Huawei P40, `android::host` path, release build: flings and scrolling as above, no panics, `droppedFrames`/`lateAcquireFrames` both 0. - `cargo check --target aarch64-linux-android` and `cargo check --target aarch64-apple-ios` both clean. Co-authored-by: 涂阳川 <yangchuan.tu@longbridge-inc.com>
huacnlee
force-pushed
the
upstream/13-use-android-s-scroll-physics-and-let-hos
branch
from
September 27, 2026 12:06
e0be2d8 to
106347e
Compare
huacnlee
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
Stack 11/13, ported from longbridge/gpui-mobile, where each layer was reviewed and merged as its own PR.
This PR is based on #59. Cross-fork PRs can't use GitHub's stacked PRs or target another PR's branch, so this diff includes every layer below it. Please review only the top commit (106347e), and merge the stack bottom-up.
Two gaps a host app hits on the
android::hostpath. Both are Android-only:everything here lives under
src/android/, whichlib.rsgates behind#[cfg(target_os = "android")], so iOS does not compile it. Verified bybuilding the crate for
aarch64-apple-ioswith these changes applied.Flings used iOS physics
AndroidPlatformnever implementedPlatform::gestures, so GPUI fell back toGestureTuning::default()— whosescroll_physicsisUIScrollView'sexponential decay. Every Android app built on gpui-mobile has therefore been
flinging with iOS physics: the content coasts much further than the platform's
own scroll views, which reads as the list not stopping where you expect.
This returns
ScrollPhysics::android()instead, the AOSPOverScrollerfriction spline that already lives in
gestures.rs. GPUI flings in logicalpixels and a window's scale factor is Android's display density, so logical
pixels are density-independent pixels and the constructor's nominal 160 dpi
pairing is the right one.
Measured on a Huawei P40 (1080x2340 @3x), same conversation and gesture script,
counting frames for 2.5s after release:
Fewer frames because the spline sheds speed faster and the fling travels a
shorter distance — the point of the change, not a regression. Frame pacing is
unchanged: 16ms intervals throughout,
droppedFrames = 0in both.The rest of
ViewConfiguration(touch slop, tap timeouts) stays on GPUI'sdefaults; reading the real values over JNI is a separate change.
A host could not install an asset source
host::starthands the launch closure a&mut App, which is one step too lateto install an asset source:
Application::with_assetsconsumes the builder, andthe builder is created inside
on_surface_createdwhere the host cannot reachit.
The failure is silent.
AssetSource::loadreturningNoneis a valid answer,so nothing logs and anything resolved through the asset source — icons, SVGs —
simply does not appear.
start_with_assetsstores the configuration step in a static thaton_surface_createdconsumes when it builds theApplication, right beforerun_embedded.startkeeps its current shape for hosts that do not need one.Testing
android::hostpath, release build: flings and scrolling asabove, no panics,
droppedFrames/lateAcquireFramesboth 0.cargo check --target aarch64-linux-androidandcargo check --target aarch64-apple-iosboth clean.🤖 Generated with Claude Code