On Wed, 14 Oct 2026 09:03:16 GMT, Jayathirth D V <[email protected]> wrote:
> > I think invalidating the flag in `setDeviceParametersFor3D` (which is what > > this PR does) should be enough for this case? > > In "3D draw -> Failed 2D draw but successful D3DShader.setConstantsF() -> > again 3D draw" scenario `setDeviceParametersFor3D` will not be called again > and light cache flag will not be invalidated. Example of 2D draw call which > can set external shader, but return without draw if source texture is not set > properly: > https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSOneSamplerPeer.java#L56. > In this case second 3D draw will have improper light constant details. 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. 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. 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. 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. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2319#issuecomment-6173226620
