Decora <> Open Shading Language?

Wed Mar 6 16:32:59 PST 2013

Hello,

just as an idea, maybe the angle project can be used to simply translate 
GLSL vertex
and fragment shader code to HLSL. GLSL would be the source shading language.

This project provides a GLES2 / WebGL runtime translation environment 
used in
google chrome and firefox, so it seems to be compliant, fast and well 
maintained.
I have no experiences with the angle project whatsoever though, but 
webGL on chrome
seems to work great.

https://code.google.com/p/angleproject/

This could provide a simple way to include resources like WebGL shaders 
from e.g. shadertoy.com
for interactive backgrounds. JavaFX could supply a "ShaderNode" where 
you can set glsl code,
add properties in subclasses that get automagically mapped to shader 
uniforms.
Alternativly, the translator could only be available for development and 
copies both glsl/hlsl
versions into a file as a deployable resource.

Kind Regards,
Dennis

On 14.02.2013 23:43, Jim Graham wrote:
> Rich's analysis is spot on from my perspective.  I don't have much time
> to work on Decora these days and most of my plans for what I would do
> are more tweaking and fixing issues that cause us headaches for our
> current usage.  For example, it was originally written to be a
> standalone package that could be integrated into Swing apps or any other
> infrastructure out there, but we've since broken just about any
> generalized mechanism in it through disuse and lack of maintenance.
> Since we don't really believe that it would ever be a standalone module
> any more, it would integrate a whole lot more directly and simply if we
> redid the interface to it to be Prism-specific.
>
> The only "marketing bullet point" advantages to switching from Decora
> would likely be possibly enabling user-supplied shaders, and also using
> it for the greater needs of 3D apps that go beyond basic pixel-shaders.
>
> We'd love to be able to leverage Decora at runtime for user-supplied
> shaders, but that is a daunting amount of work since much of its actions
> rely on being able to use javac and/or a native C, GSL, or HLSL compiler
> to finish the work after the "decora compiler" does the translations -
> i.e. it translates form HSL into various other forms of source code and
> then runs other compilers on those.  What we would probably have to do
> is to provide a way for a developer to run the decora compiler alongside
> his FX app and then include the various compiled alternative results,
> but that would require building on multiple platforms to produce all of
> the necessary files that are needed on an arbitrary target computer
> (minimally, building on Windows could net a GLS, an HLSL, and a Java
> version of the shader so that may be enough, but Mac developers would be
> out of luck for producing Win-specific output).  We'd also have to do a
> security analysis of accepting compiled GSL and HLSL shaders in a
> non-privileged deployment (the least common denominator work around
> would be to only allow the Java-compiled versions of the shaders in the
> absence of a signed app, but the performance on those would likely be
> lower than something that the developer wrote themselves in hand-tuned
> Java).  So, there are a lot of issues to consider and work on there
> before we could use Decora to provide user-supplied shaders.
>
> It may be less work to provide the GPU plugins for OSL than to figure
> out a workaround for the need for a compiler in Decora.  We'd also
> leverage a larger development community for the more common parts of it.
>    But, we'd also have to do a large security review of it every single
> time we brought over a new source drop from it and the complexity of
> that security review would involve analyzing the byte-code they produce
> and all elements of their runtime to make sure that a hostile OSL
> byte-code file couldn't break us.  Using this "off the shelf" technology
> sounds attractive, but integrating a 3rd party solution often has its
> own headaches that you don't see when you are in the honeymoon phase
> after having read all of the marketing bullet points.  :(
>
> I think a first task should be to get to the point where "Jim" isn't the
> only engineer with more than a passing understanding of what goes on
> with Decora under the hood - particularly since I don't have much time
> to do a more indepth analysis of competing technologies like this.  Any
> volunteers that are fascinated by the world of shaders?
>
> 			...jim
>
> On 2/14/13 1:52 PM, Richard Bair wrote:
>> Hi Philip,
>>
>> Very interesting link. I didn't clone the repo and check, I'm not sure how long it has been around. We've had Decora for 5 years I think, so we may predate it substantially.
>>
>> Adobe also has a shader technology called Pixel Bender (http://www.adobe.com/devnet/pixelbender.html). The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D https://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html).
>>
>> Although we use Decora for our shaders, we haven't done much more than keep it running. Jim Graham has had a number of ideas about things he wanted to do to move Decora forward (maybe he can chime in with those).
>>
>> There are Pros / Cons to each:
>>
>> OSL:
>>     Pros:
>> 	- It looks like Sony Pictures is continuing to work on OSL, it wasn't a dump & forget.
>> 	- Any time multiple companies can contribute to the same thing, the better chance of broader adoption (& tools etc)
>> 	- Being able to leverage other's work instead of doing all the work ourselves could free us from some maintenance costs
>>     Cons:
>> 	- Different design center -- doesn't yet support GPUs for instance
>> 	- Lack of tooling
>>
>> Pixel Bender:
>>     Pros:
>> 	- Great tooling support
>> 	- Same design center -- shaders for 2D / 3D applications
>> 	- Robust
>> 	- Leverage Adobe's investment
>>     Cons:
>> 	- License is proprietary according to wikipedia, not sure myself
>> 	- Not sure of the runtime size
>> 	- Needs to be vetted for security risks
>>
>> Decora:
>>     Pros:
>> 	- Does exactly what we need -- no more
>> 	- Small size (no features we don't need)
>>     Cons:
>> 	- No time to invest in serious upgrades
>> 	- No tooling support
>>
>> I think that's a fair portrayal of the situation. From a pragmatic perspective it seems like supporting Pixel Bender would be a great way forward, but I don't know what the license situation is (i.e.: would we have to provide our own compiler, or could we reuse their compiler? Can we even do that much?). Given we haven't had time to spend improving decora, replacing it would be even more work.
>>
>> However, I wouldn't be opposed to using OSL or Pixel Bender or any other system if the benefits outweigh the costs.
>>
>> Richard
>>
>>
>> On Feb 14, 2013, at 1:49 AM, Philipp D?rfler <phdoerfler at gmail.com> wrote:
>>
>>> Here is the link:
>>> [1] http://opensource.imageworks.com/?p=osl
>>>
>>> Am 14.02.2013 um 10:48 schrieb Philipp D?rfler <phdoerfler at gmail.com>:
>>>
>>>> Greetings,
>>>>
>>>> I stumbled upon the Open Shading Language [1] which seems to be an already established standard and uses LLVM to optimize shaders. I wonder why this is not used instead of / as a backend for Decora. Might you please shed some light on that?
>>>>
>>>> Cheers and thanks in advance
>>>> ~ Philipp