[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] The state of MRTs

Well for what it's worth I totally agree on these. Like most of this stuff we have to  plan adequate fallbacks for any extension that isn't implemented, so to my mind there aren't many reasons not to implement it for those that can support it.

I particularly agree that it should lead to more impressive work that could well help WebGL adoption.

On 20 Mar 2012, at 18:56, "Gregg Tavares (勤)" <gman@google.com> wrote:

So I've been meaning to propose this. Here's a first stab

Whether there's any chance to get it approved by the group I don't know.

Arguments for:

*) Multiple render targets are super awesome! Lots, in fact most modern graphics applications use this feature extensively. Supporting it will go a long way to helping adoption of WebGL with more impressive apps. 

*) It's not really a new feature. No new APIs are added. It's similar to texture fetch in vertex shaders where the max allowed is allowed to be 1.

*) It's relatively easy to implement

*) It doesn't raise any extra security or validation issues that I know of. 

Arguments against:

*) Some mobile hardware only supports 1 target.

I don't really see that as much a valid argument in that some day this feature will be supported one way or another (WebGL 2.0?), at that point the same issue will exist, some hardware will support 0, some 4, some 8, some 16, etc.. Apps that use multiple render targets will have to have fallbacks for hardware that doesn't support the number they ideally need. So, why not just expose it now?