Decora <> Open Shading Language?

Jim Graham james.graham at
Thu Feb 14 14:43:17 PST 2013

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?


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 ( The nice thing about their language is that their designer tools support Pixel Bender (and I guess AGAL and Pixel Bender 3D
> 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> wrote:
>> Here is the link:
>> [1]
>> Am 14.02.2013 um 10:48 schrieb Philipp Dörfler <phdoerfler at>:
>>> 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

More information about the openjfx-dev mailing list