DrawCalls::new receives get_use_direct_draw() where use_compute_culling is expected
The bug
DrawCalls::new's second parameter is use_compute_culling:
// crates/renderling/src/draw/cpu.rs
pub fn new(
ctx: &Context,
use_compute_culling: bool, // <-- expects the compute-culling flag
...
But the call site passes the inverted value:
// crates/renderling/src/stage/cpu.rs:1223
DrawCalls::new(
ctx,
ctx.get_use_direct_draw(), // <-- returns !use_compute_culling
...
Context::get_use_direct_draw() returns !use_compute_culling, so the two
flags cancel out and the drawing strategy is always chosen opposite to the
documented behavior:
Context::set_use_direct_draw(true) (documented: "all compute culling will not run") actually enables the indirect/compute-culled path
Context::set_use_direct_draw(false) disables it
Consequences
The default GlobalStageConfig.use_compute_culling is false, so with the
inverted wiring the effective default rendering path today is indirect
(compute culling) — which likely matches intent, but only by accident of the
double inversion.
Evidence
Found while writing the debug-modes manual chapter. With a default headless
context, DrawCalls::pre_draw returns an indirect draw buffer (Some), so the
GPU-driven path is active. With Context::headless(w, h).with_use_direct_draw(false)
— which per the docs should keep the indirect path — pre_draw returns
None, proving the flip. Instrumented run:
ctx = Context::headless(512, 512) -> maybe_indirect_buffer = Some
ctx = Context::headless(512, 512).with_use_direct_draw(false) -> maybe_indirect_buffer = None
Fix considerations
Passing the correct value (e.g. !ctx.get_use_direct_draw()) flips the
default rendering path from indirect to direct drawing unless the
GlobalStageConfig default for use_compute_culling also changes to true.
That behavior decision belongs to the maintainer:
- Option A: fix the call site and set the config default
use_compute_culling: true — keeps today's effective default (indirect/compute-culled) while making the API honest.
- Option B: fix only the call site — the default becomes direct drawing, matching the config default but changing behavior for every existing user.
DrawCalls::newreceivesget_use_direct_draw()whereuse_compute_cullingis expectedThe bug
DrawCalls::new's second parameter isuse_compute_culling:But the call site passes the inverted value:
Context::get_use_direct_draw()returns!use_compute_culling, so the twoflags cancel out and the drawing strategy is always chosen opposite to the
documented behavior:
Context::set_use_direct_draw(true)(documented: "all compute culling will not run") actually enables the indirect/compute-culled pathContext::set_use_direct_draw(false)disables itConsequences
The default
GlobalStageConfig.use_compute_cullingisfalse, so with theinverted wiring the effective default rendering path today is indirect
(compute culling) — which likely matches intent, but only by accident of the
double inversion.
Evidence
Found while writing the debug-modes manual chapter. With a default headless
context,
DrawCalls::pre_drawreturns an indirect draw buffer (Some), so theGPU-driven path is active. With
Context::headless(w, h).with_use_direct_draw(false)— which per the docs should keep the indirect path —
pre_drawreturnsNone, proving the flip. Instrumented run:Fix considerations
Passing the correct value (e.g.
!ctx.get_use_direct_draw()) flips thedefault rendering path from indirect to direct drawing unless the
GlobalStageConfigdefault foruse_compute_cullingalso changes totrue.That behavior decision belongs to the maintainer:
use_compute_culling: true— keeps today's effective default (indirect/compute-culled) while making the API honest.