I've thought about this too for a bit. My question would be how to tell the CPU what data to pass to the shader. Take OpenGL for example: writing an API to pass a shader and compiling it in runtime is not hard, but you need the CPU side to feed the shader its parameters. You would need an API for arbitrary data that the shader has been preconfigured to handle. That's quite an undertaking. And what level of flexibility is this going to give? The shader might require data that the public Java API does not expose, so you are limited in that regard too. When I wrote the enhancements for the shaders, I also had to change the Java side, which you won't be able to do. On the D3D side, the shaders are precompiled, so it's a slightly different story.
- Can high school students sign the OCA? (I saw the job title field > on the form and wasn't so sure I was legally allowed to sign it) Maybe ask on adoption-disc...@openjdk.java.net. On Mon, Mar 15, 2021 at 1:50 AM Michael Ennen <mike.en...@gmail.com> wrote: > I messed around with adding features to JavaFX's "JSLC" (Java Shader > Language Compiler) which currently is only used > at compile-time for JavaFX to convert "JSL" shaders to various platform > dependent shader languages (GLSL, HLSL, etc.). > > In my opinion the ideal way to implement a public shader API would be to > extend JSLC to be able to be used either > at user application compile time, or more ideally, at application run-time > to dynamically generate platform dependent shaders > depending on what platform JavaFX is running on. Then a JavaFX application > developer can write platform independent > shaders in JSL. This would be quite a large undertaking and have a high > burden of maintenance to keep it current with > fast moving shader languages. > > I was able to convert JSLC grammar to antlr4 (from the previous antlr3 > version) in this merged commit (pre-dates the move > to Github): > > > https://github.com/openjdk/jfx/commit/52adea7c3635656421db766641416ff28213928f#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > I then took advantage of a new feature in antlr4 which allows for > extracting embedded actions from the grammar definition file to a visitor > class: > > > https://github.com/openjdk/jfx/commit/8889330cc30a47361d47519be2ec662fb5ebe856#diff-9c8e9478200eb2c014c196feec63537046751c0d6fe80f90b8506b11abfcc2f7 > > I then, in a test repository did some work in fleshing out what it would > take to implement more features for JSLC which you can find (as messy > commits) here: > > https://github.com/brcolow/jslc > > That's just my two cents on how a public shader API should best be added to > JavaFX, by building on previous work that exists in the source code > repository but is only > used in a very limited and small way - but there is much potential there > and I believe the original author of JSL's intent was to have it be a > public API feature to allow > JavaFX developers to write platform independent shaders in JSL. > > > On Sun, Mar 14, 2021 at 3:32 PM superminerJG <jackyguo...@gmail.com> > wrote: > > > Hi everyone. > > > > This problem might have been discussed numerous times, and has been held > > off for quite a while. > > > > Although we are starting to see lighting improvements added to JavaFX, I > > feel that it's necessary for JavaFX to have some kind of custom shader > > pipeline. However, nobody has gotten around to doing it, so I thought > that > > I could lend a hand. Before I get into things, I would like to know how > and > > what I can contribute. The questions are at the bottom of the email. > > > > Thanks! > > - jgcodes > > > > Questions: > > > > - Can high school students sign the OCA? (I saw the job title field on > > the form and wasn't so sure I was legally allowed to sign it) > > - When I implement the shader API, should it use some kind of GLSL > > mapping, or should I try to extend JSL to work in 3D? > > - Should I have sent this email to another mailing list? > > > > > -- > Michael Ennen >
