Problem
CompositeEffectPass is typed as an EffectPass without fragment and vertex, so it promises the standard pass contract. Its implementation does not fulfill key parts of that contract:
- The inherited API advertises
render({ target, clear }), but composite render() accepts no options and ignores overrides.
onUpdated is typed as updates to the composite uniform object, but it forwards child-pass updates instead.
- Direct writes to
composite.uniforms do not use a reactive proxy and emit no update event.
- Callback hooks use
any despite the generic public type.
Impact
Consumers cannot write generic code over EffectPass | CompositeEffectPass safely. Render target overrides and clear behavior can fail silently, while render-on-demand code gets misleading update events. These inconsistencies will make nested composites and graph-level tooling difficult to add compatibly.
Relevant code
lib/src/passes/compositeEffectPass.ts:20-43,55-88
lib/src/passes/renderPass.ts:113-153,241-288
Proposed API decision
Create and export a shared render-options type:
type RenderOptions = {
target?: RenderTarget | null;
clear?: boolean;
};
Every renderable pass should implement render(options?: RenderOptions): void.
For composites:
- Apply
target to the final output child.
- Define and document whether
clear applies only to that child or to each child.
- Make composite uniforms reactive, with
onUpdated emitting only composite-uniform changes.
- If child changes need to be observable, expose a separate explicitly typed callback that identifies the child pass.
Acceptance criteria
Problem
CompositeEffectPassis typed as anEffectPasswithoutfragmentandvertex, so it promises the standard pass contract. Its implementation does not fulfill key parts of that contract:render({ target, clear }), but compositerender()accepts no options and ignores overrides.onUpdatedis typed as updates to the composite uniform object, but it forwards child-pass updates instead.composite.uniformsdo not use a reactive proxy and emit no update event.anydespite the generic public type.Impact
Consumers cannot write generic code over
EffectPass | CompositeEffectPasssafely. Render target overrides and clear behavior can fail silently, while render-on-demand code gets misleading update events. These inconsistencies will make nested composites and graph-level tooling difficult to add compatibly.Relevant code
lib/src/passes/compositeEffectPass.ts:20-43,55-88lib/src/passes/renderPass.ts:113-153,241-288Proposed API decision
Create and export a shared render-options type:
Every renderable pass should implement
render(options?: RenderOptions): void.For composites:
targetto the final output child.clearapplies only to that child or to each child.onUpdatedemitting only composite-uniform changes.Acceptance criteria
renderaccepts and implements shared render options.onUpdatedaccurately represents composite uniform mutations.anyis required for composite hooks.render(options)safely.