Decora <> Open Shading Language?

Thu Feb 14 15:39:31 PST 2013

Thanks for your elaborate replies and for providing insight into Decora. It's a shame it took this course given how high the original hopes had been. The reasons for this development are all quite understandable and I share your pain, for that matter. Still: Decora would certainly be an awesome stand alone tool and given that you guys are busy open sourcing JavaFX I might feel tempted to write a tiny shader editor on top of it (once I'll have time for that, aka never).

Regarding OSL and Pixel Bender:
According to GitHub, the first commit [1] was on 2008-09-03, 4 years ago. So indeed, Decora predates OSL. From what I've heard the Blender community is currently adapting their shader code to OSL. Hopefully it will gain more momentum and interest so it might become a viable alternative or supplement for Decora.
I was unaware of Pixel Bender and have to say it looks rather promising though the disadvantages mentioned are deterrent.

Again thanks for your detailed replies. It's nice to see how much you care about Decora :)

[1] https://github.com/imageworks/OpenShadingLanguage/commit/ed210bbb0c5c74ad0b82c4a8a949ab97d1aa0ad6

Am 14.02.2013 um 23:43 schrieb Jim Graham <james.graham at oracle.com>:

> 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
>>> 
>> 