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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification



And now the more diplomatic version of that reply ;-D

We're on the same page. We agree having features that make WebGL more debuggable is great. We just disagree on the best road to get there.

I thought my suggestion was actually getting WebGL debuggable faster with far less work and far more flexibility. 5+ browser teams don't need to implement it only 1 team that that 1 team doesn't have to be anyone from a browser team who's currently trying to ship WebGL 2.0 but instead will have to add this to their stuff of stuff to do before it can ship. No arguing what the format should be or what features or which error has to be caught first or how many errors are required to be reported per complication or if there should be warnings for undefined behavior or unused variables or code or etc etc etc...  And, you can have it probably in a week or two if someone set out to write it whereas if you go the spec route you probably won't get it for 12-18 months.

Can you imagine how long it would have been for WebGL debugging tools if instead of Ben Vanik just making one, he instead came here and demanded we make an official spec for one and then waited for some browser team to implement it?

BTW: you probably know this but GL doesn't require error messages period. Nor does it require any errors at compile time.


On Wed, Jan 7, 2015 at 11:40 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Thu, Jan 8, 2015 at 8:37 AM, Gregg Tavares <khronos@greggman.com> wrote:
I think as a library it's a great idea but I don't see how putting this in the browser or the official spec would be anything but a giant time sink. Time that would be better spent implementing a library or shipping the next couple versions of WebGL

Oh yeah, I'm sure that ensuring that WebGL is easily and out of the box debuggable is one of those huge timewasters, why bother eye mate?