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

Frame rate on and near Earth's surface: 30–40 FPS against 60 in space

Open
  • Is something wrong?
#189 4 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
28/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, three.js
Domain
computer-graphics, performance

Research direction

Start by measuring on the user's real GPU; the issue names AGENTS.md as the place to document the ?perf=1 overlay. Inspect the meter readback, night-lights rendering, atmosphere pass, cloud shell (#88), and galaxy and night-sky passes, then use per-pass timings and toggles to prioritize costs. Done means surface views reach 50–60 FPS on the user's machine, or each remaining cost is measured and its reason recorded.

Written by the indexing model from the issue text.

Description

track:platform

Part of #121.

The problem

Production frame rates on a real GPU (the user's Mac, Brave):

View FPS
Space about 60
On or near Earth's surface, even looking down with no sky in view 30–40
Looking at the Sun from the surface by day, with time running 18–20 (seen on PR #187)

PR #187 is fixing its own surface regression (about 20 against 30–40) separately. This issue is the headroom on main.

Known or suspected costs on the surface

  • Cesium's draws run twice. The shadow context executes every draw as well as the replay (#103, upstream in portal-netgl).
  • The night lights are a second, unlit Cesium frame plus a decode pass (#93, PR #179). Check whether it renders on the day side, or when the night side isn't in view.
  • The meter's synchronous readback every 4th frame stalls the pipeline (found on #187). Make it asynchronous: a PBO plus fenceSync/clientWaitSync polling, read a frame or two late.
  • The atmosphere pass at full resolution, the cloud shell (#88), and the galaxy and night-sky passes. Each should cost nothing when its result can't show.

The work

  1. Measure on the real GPU first. The sandbox's SwiftShader can't time GPU work. Add a ?perf=1 overlay with per-pass GPU timings (EXT_disjoint_timer_query_webgl2 where available). Where it isn't, show CPU-side timings plus per-frame counts of draws, full-screen passes, render-target switches and readbacks, and URL toggles to switch each pass off, so the user can bisect the cost on their machine. Document it in AGENTS.md.
  2. With the user's numbers, take the biggest costs in order:
    • the asynchronous meter readback;
    • skipping invisible work (night lights by day, passes whose result is under a display step);
    • the atmosphere pass's resolution;
    • #103 upstream.

Done when

On the user's machine, the surface views reach at least 50–60 FPS, or each remaining cost is measured and recorded with the reason it stays.

Generated by Claude Code

Dominant language
JavaScript
Stars
55
Forks
4
Avg merge
10h 12m
Merged PRs (30d)
134

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

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 celestiary/web

All issues in celestiary/web

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.