Tinted

@Composable



fun Tinted(
    tint: () -> Int, 
    modifier: Modifier = Modifier, 
    content: @Composable



 () -> Unit
)

Tints content's own entire rendered subtree - background sprites, text, everything it draws, not merely something drawn over top of it - by tint (a packed ARGB int; -1/0xFFFFFFFF is fully opaque white, i.e. no tint at all), via RenderSystem.setShaderColor. This is what makes every themed composable's own net.kernelpanicsoft.archie.gui.util.extension.drawThemeState call automatically tint-aware (it reads back whatever RenderSystem.getShaderColor currently has active) without each one needing to know or care that fading/greying is even happening - the same reason vanilla's own hurt-flash/fade-to-black effects use this exact mechanism rather than drawing an overlay quad, which could only ever dim/tint what's underneath, never genuinely desaturate or fade something translucent-looking in and out.

tint is re-evaluated fresh every render frame, not memoized against recomposition - a caller wanting a continuously time-varying tint (a pulse, say) can simply read System.currentTimeMillis inside it directly, the same pattern every other time-driven visual in this GUI framework already uses (a connector's own flow/wave phase, say), since a composable body only re-runs on state change, not every frame, but a Renderer.render callback does.

Nests correctly via tintStack - an already-tinted subtree containing another Tinted multiplies the two together (multiplyArgb) rather than one clobbering the other, and each Tinted's own renderAfterChildren restores exactly the ambient tint it interrupted, not an unconditional reset to opaque. RenderSystem's own shader color is global GPU state, so an explicit GuiGraphics.flush both before changing it and after restoring it is required, not optional - without the first, anything already queued (but not yet actually rasterized) from an earlier sibling would unexpectedly pick up this node's own tint once its buffer's own later flush finally runs; without the second, this node's own tint would just as unexpectedly leak onto whatever's queued right after it. The exact same class of hazard (Mojang's buffered MultiBufferSource flushing whatever it's holding in its own RenderType-keyed order, not necessarily the order draw calls were issued in) that made an explicit flush the fix for the modal backdrop dimming its own dialog panel instead of just what's behind it - see net.kernelpanicsoft.archie.gui.ComposeContainerScreen's own render.