[Bug]: Server preview browser is laggy: always launched with --disable-gpu and device scale 2
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 74/100
- issue の種類
- バグ
- 明瞭さ
- 明確に書かれている
- 活発さ
- 活発
- 技術スタック
- typescript
- 領域
- backend, performance
調査の方向性
apps/server の ServerBrowserContexts.launchOptions() から調査を始めてください。ここでは --disable-gpu と --force-device-scale-factor=2 が固定値として埋め込まれています。これらのオプションが chrome-headless-shell にどこで渡されるかを追跡してください。サーバーのプレビューまたは小さなヘッドレスのスクリーンキャストで現在の起動フラグを再現し、そのうえで GPU の経路とスケールファクターを、オペレーターの設定または検出によって設定可能にしてください。これらのフラグが無条件に適用されなくなり、対応可能なホストでプレビューが適切な倍率で GPU の経路を使えるようになれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- Run the T3 server on a Linux host that has a GPU. Here: Ryzen 9 5950X (32 threads), RTX 3080 Ti with
/dev/dri/renderD128available, client 0.2 ms away on gigabit. - Open a thread's server preview browser on a normal web app, such as a React dashboard with a long table.
- Scroll or interact with the page.
Expected behavior
The preview stays smooth. The page renders at 60 fps on that host, and the client link has plenty of headroom.
Actual behavior
The preview is laggy enough to be unusable for interactive work.
The network is not the cause. Between client and server I measured 0.2 ms RTT and 897 Mbit/s over Tailscale on a direct path (948 Mbit/s on the LAN). The server is mostly idle (load ~4 of 32).
The limit is on the capture side. ServerBrowserContexts.launchOptions() always passes --disable-gpu and --force-device-scale-factor=2, so every frame is rasterized in software (SwiftShader) at 4× the pixels, then JPEG-encoded.
I ran a standalone benchmark on the server itself, with no network involved. It used the same chrome-headless-shell 156.0.8078.70 that T3 downloads, a 1440×900 viewport and Page.startScreencast (JPEG, quality 80), with each frame acked on receipt. For 10 s the page scrolled 40 px on every requestAnimationFrame:
| Launch flags | Screencast fps | KB/frame | Mbit/s | Server CPU |
|---|---|---|---|---|
as T3 launches now (--disable-gpu, SwiftShader, scale 2) |
30.8 | 348 | 88 | 2.8 cores |
GPU (--use-gl=angle --use-angle=gl-egl --ignore-gpu-blocklist --enable-gpu), scale 2 |
54.0 | 347 | 153 | 8.8 cores |
| GPU, scale 1 | 60.0 | 136 | 67 | 2.8 cores |
- The page itself paints at 60 fps. The loss is in software raster at scale 2.
- With the GPU flags, WebGL reports the NVIDIA renderer, so the GPU path works in this headless shell.
Impact
The server preview browser is the main way to look at and drive a dev app from a remote T3 client. On this hardware it is too laggy to use for clicking through a UI. The only alternative is opening the app directly in a local browser, which defeats the feature.
Version or commit
T3 0.1.4-nightly.20261027.3796. chrome-headless-shell 156.0.8078.70 (linux64).
Environment
- Server: Linux LXC container on Proxmox, NVIDIA driver with
/dev/dri/renderD128passed through. - Client: Chrome on Windows 11, connected over Tailscale (direct path).
Possible fix
- Don't force
--disable-gpuwhen the host has a usable GPU. This could be an operator opt-in env, likeT3CODE_SERVER_BROWSER_SANDBOX, or a detected default. - Make the device scale factor configurable. With the GPU, scale 1 reaches 60 fps at the same CPU as today and 60% smaller frames.
I'm happy to test a build.
Workaround
None on the server: the flags are hard-coded and there is no env override. Opening the app in a local browser works.
- 主要言語
- TypeScript
- スター
- 24.8k
- フォーク
- 6.4k
- 平均マージ
- 2時間 54分
- マージ済み PR（30日）
- 350
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
pingdotgg/t3code のほかの issue
-
[Bug]: Pen taps on sidebar rows start a drag and lose their click対応中かも @makhnatkin が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 62/100
メンテナーはふだん 1 日以内に返信
-
[Bug]: Guest messages near the 4,000-char limit fail with 400 "The request was not valid." because multipart turns \n into \r\n対応中かも @juliusmarminge が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
[Bug]: preview_evaluate forbids WebMCP write tools even when the user explicitly asks for the change対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープンbug needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 60/100
pingdotgg/t3code#26340 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
pingdotgg/t3code の issue をすべて見る
似ている issue
-
難易度 1/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
-
area:plugins area:security area:skills bug has repro
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
anthropics/claude-code#105911 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
dev-five-git/devup-ui#879 ·
メンテナーはふだん 11 日以内に返信
-
openspec-apply-change skill: when blocked, may select a ready artifact unrelated to missingArtifactsオープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
Fission-AI/OpenSpec#2165 ·
メンテナーはふだん 1 日以内に返信
-
🐞 bug 🧐 unconfirmed
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
Tencent/tdesign-vue-next#7032 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信