RFR: 8336624: Improve Decora Shader loading for modern APIs

[Lukasz Kostyra]

On Mon, 5 Aug 2024 16:02:00 GMT, Lukasz Kostyra <lkostyra at openjdk.org> wrote:

> In modern graphics APIs having the knowledge of Shader's name can be necessary - whether it is because of a different Shader storage/loading behavior, or to fetch some additional metadata generated upon Shader precompilation. A good example is shown on development branch for Metal backend, where [a temporary workaround was added](https://github.com/openjdk/jfx-sandbox/blob/metal/modules/javafx.graphics/src/main/java/com/sun/scenario/effect/impl/prism/ps/PPSRenderer.java#L270) to provide Metal with loaded Shader's name. Metal API uses shaders stored in a Metal-specific shader library, which makes our "usual ways" of loading shader code and providing it via an InputStream not possible.
> 
> This change resolves above problem by adding a `pixelShaderName` argument to `ShaderFactory` interface. Additionally, Glue template for Prism Shaders was updated to also provide both Shader's name and Shader code to the backend. Thanks to this change, Prism backends can determine the best course of action - old backends can ignore newly added `pixelShaderName` parameter and proceed "as usual", while new backends like Metal can adjust shader loading for their needs.
> 
> Both D3D and ES2 Prism backends were updated to properly handle these changes.
> 
> NOTE: Because Glue template was changed for Prism stock shaders, it might be necessary to run a full clean-rebuild sequence to regenerate JSL Shaders and properly test this change.
> 
> I tested this change on Windows, macOS and Linux, both full test run and by randomly picking Ensemble8 examples.

@arapte Please take a look at this and confirm if those changes will be good for Metal

-------------

PR Comment: https://git.openjdk.org/jfx/pull/1530#issuecomment-2269416642