Shader API proposal

[Nir Lisker]

I think that the best initial approach would be hands-on. Learn the current
shader rendering chain:
1. The implementation of Shape3D, LightBase and PhongMaterial.
2. The native pipelines. The java side graphics contexts send the relevant
data to the native context.
3. The shaders. The native contexts pass on the data to the shaders.

Try to make modifications to the public Java API that requires
modifications in the shaders and change them accordingly so you'll get a
full start-to-finish test feature, This will give you an idea of what it
entails. Even if you do this for only 1 of the pipelines it's good enough.
>From there you can start abstracting the idea.
That would be my suggestion.

- Nir

On Wed, Mar 17, 2021 at 3:15 AM Jacky Guo <jackyguo579 at gmail.com> wrote:

> This is my proposal as to how the shader API should work:
>
> In javafx.scene.paint 2 new classes would be added:
>
>    - Shader
>    - ShadedMaterial
>
> ShadedMaterial would contain methods relating to the material itself,
> probably including texture maps and the like.
>
> Shader would contain more low-level functions, like passing values to the
> shader or similar.
>
> I'm not sure if all the functionality should belong to one class, but in
> my mind, separating it like this will have its benefits.
>
> In addition, I haven't dabbled much with native graphics, so I will be
> needing some guidance on that end.
>