Expand description
What this build is running on — the ONE record of it.
Two places need to say which renderer is in use: the Info window (so a user
can read it) and the problem report (so a triager can read it about a user
who is not there to ask). They must never be able to disagree, so there is
one collector — this — and both read the SAME Diagnostics instance. The
window renders Diagnostics::rows; the report embeds
Diagnostics::report_text, which is those very rows joined. A row added
here appears in both, and neither can carry a value the other does not.
§Why it is captured, never probed
The renderer is CHOSEN once, at startup, by eframe: wgpu’s
new_instance_with_webgpu_detection drops BROWSER_WEBGPU from the backend
set when the browser has no WebGPU adapter (or the page is not a secure
context), so the instance falls through to WebGL2. That choice is a fact of
the running session, and the adapter that made it is the one drawing every
frame — so we read it where eframe hands it to us
(Diagnostics::from_render_state, called from BrepApp::new_with) and
keep it.
Asking the question a SECOND time later — a fresh request_adapter, say —
would be a different question with its own answer: an adapter enumeration at
report time can succeed where the startup one failed (or pick differently),
and a diagnostic that disagrees with what is on screen is worse than none at
all, precisely in the case someone is filing a bug about the renderer.
§What it may contain
Hardware and build facts only: the backend, the adapter, the one adapter limit that bounds what the viewport can allocate, the app version and the target. The report already sends a screenshot, the model and an optional email; this adds nothing that identifies a PERSON, and it must stay that way — a report’s description is served publicly by the reports endpoint.
Structs§
- Diagnostics
- The startup facts about this session’s renderer and build.