On Wed, 14 Oct 2026 16:33:02 GMT, Nir Lisker <[email protected]> wrote:
> > It looks to me more like a problem in the effects code. It first sets/updates > the shader, and then does the write check (`if (ptex == null)`. That check > should be done prior to making changes. It also means that > `g.setExternalShader(null)` isn't called when the check doesn't pass, so > later renders still use this one's shader. `PPSTwoSamplerPeer` does the same > thing. Yes state management here is not proper. > > Another solution is to not reuse the Phong shader reserved register blocks > and dedicate blocks for the 2D shaders. It's a bigger change and depends on > what happens in other pipelines. Right now there is no such restriction and yes it will be a larger change. > > Looking forward, I understand now that this issue stems from the > now-incorrect assumption that all the constants are reuploaded on every call, > so leaving a dirty state didn't matter. Now that we cache, collisions with > the lights registers surface this problem. If we later cache the materials as > well, for example, we might hit the same problem. I didn't look at caching > other constants, but now that I think about it it's a good direction to > investigate later on. Yes since we are caching now and there are conditions where constants are not getting reuploaded on every call, we will end up in wrong state of these registers. > > I can still add the native-side guard if you prefer, but I'm not convinced > it's the right place for a true fix. Now when i re-think, i feel this is needed because we have scenarios which doesn't make light constants state fool proof. Effects related state management can be handled in separate bug: [JDK-8394615](https://bugs.openjdk.org/browse/JDK-8394615) ------------- PR Comment: https://git.openjdk.org/jfx/pull/2319#issuecomment-6186108992
