Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: Server preview browser is laggy: always launched with --disable-gpu and device scale 2

Open Beginner friendly
  • Is something wrong?
#26,523 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
backend, performance

Research direction

Start in apps/server at ServerBrowserContexts.launchOptions(), where --disable-gpu and --force-device-scale-factor=2 are hard-coded, and trace where those options are passed to chrome-headless-shell. Reproduce the current launch flags with the server preview or a small headless screencast, then make the GPU path and scale factor configurable via an operator setting or detection. Done when those flags are no longer unconditional and the preview can use the GPU path at a sensible scale on a capable host.

Written by the indexing model from the issue text.

Description

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
  1. Run the T3 server on a Linux host that has a GPU. Here: Ryzen 9 5950X (32 threads), RTX 3080 Ti with /dev/dri/renderD128 available, client 0.2 ms away on gigabit.
  2. Open a thread's server preview browser on a normal web app, such as a React dashboard with a long table.
  3. 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/renderD128 passed through.
  • Client: Chrome on Windows 11, connected over Tailscale (direct path).
Possible fix
  • Don't force --disable-gpu when the host has a usable GPU. This could be an operator opt-in env, like T3CODE_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.

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
2h 54m
Merged PRs (30d)
350

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.