[P2][RENDER] Per-scene render-quality autotuning without surprise behavior

Open
  • Is something wrong?
#163 0 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
55/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
computer-graphics, performance

Research direction

Read src/three/quality.rs, src/render/gpu.rs, and src/render/timer.rs, then review the history of #151, #157, and #158 for render-scale changes and history resets. Start by testing a controller with recorded optional GPU timings, checking bounds and hysteresis before live integration. Done means an opt-in, documented adjustment that protects explicit settings and screenshot tests, avoids oscillation, and never uses CPU time when GPU data is unavailable.

Written by the indexing model from the issue text.

Description

area: rendering help wanted priority: P2 type: feature

Problem and goal

Desktop and mobile GPUs vary dramatically; quality presets exist but are static.

Implementation scope

  • Research optional scene-level automatic render scale/shadow quality adjustments using GPU frame timings.
  • Protect explicit user settings and deterministic screenshot tests.
  • Introduce hysteresis and safe bounds; never change quality when performance data is unavailable.
  • Expose active quality choices and why they changed.

Acceptance criteria

  • Opt-in only and documented.
  • No quality oscillation under controlled fluctuating GPU load.
  • No feature selection based on unreliable CPU frame time as a GPU proxy.

Relevant code

  • src/three/quality.rs
  • src/render/gpu.rs
  • src/render/timer.rs

Dependencies and notes

After performance profiling and GPU capability tiers.

Compatibility: preserve existing public Rust and C/C++ APIs unless an independently approved design explicitly requires a breaking change. Collect correctness results and before/after measurements for performance-oriented changes.

Source audit and first contribution (2026-11-09)

Reviewed against source baseline df5c1d4 and merged implementation PRs through #167. The full issue acceptance criteria are still open; this audit does not mark the task complete. Existing priority is unchanged.

Starting point: Static quality presets and optional GPU timing exist; autonomous quality adjustment is still planned.

First slice: Test a controller against recorded optional GPU timings, bounds and hysteresis before live integration.

Dependencies and coordination: Use #151/#157 and #158 history resets for render-scale changes. Never substitute CPU time for absent GPU measurements.

Focused Rust-only PRs are welcome; a contributor need not complete this entire issue in one PR or also implement C/C++ bindings and guide chapters. Maintainers coordinate scoped documentation/native follow-ups. Preserve existing compatibility and supply tests/evidence relevant to the slice.

Dominant language
Rust
Stars
4
Forks
0
Avg merge
45m
Merged PRs (30d)
199

Getting set up

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 ponkoengine/ponko

All issues in ponkoengine/ponko

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.