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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification

On Fri, Jan 9, 2015 at 12:27 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Fri, Jan 9, 2015 at 9:05 AM, Gregg Tavares <khronos@greggman.com> wrote:
I don't know if you were suggesting my solution was "duct-tape and chickenwire". If you were I don't see it that way. I see my solution as vastly superior for all the reasons stated. 
By that logic, it's futile to have a standard, about anything, in the first place, let's just half-arse-wing it and throw duct-tape and chickenwire at everything. Heck, why have conformance test? That's circularly self referencing nonsense.
To reiterate

*) less man work
*) covers more browsers
*) requires no debate on specs or features
*) doesn't add to the already full plates of browser teams
*) can be expanded without more debate and specing
*) is more flexible
*) will be available sooner
*) bugs can be fixed immediately without waiting for some browser team to find time to fix them
*) bug fixes available immediately, no waiting several months for a them to bubble through browser release cycles.
That's not what it's about, so that's completely irrelevant.
Error info log messages are part of the API, intended for machine consumption.

No they aren't. Error Info Log messages are speced such that they can always be empty. It is purely up to the driver implementor if they want to return anything there or not. The only error related to GLSL that's required is that bad shaders return false for gl.LINK_STATUS at LINK time. They are free to return success even on bad shaders at COMPILE time.  Everything else is optional. I know this because I had to fix all the webgl conformance tests that used to require failure at compile time.

I didn't say that was how it is. I said, that is what the consensus should be. I said it, I know, I just wrote it in the message before, which, you probably didn't read.

I think you're underestimating the amount of work. Let's assume it's just Chrome (since that's what I know) It's not just formatting messages in ANGLE. ANGLE isn't guaranteed to catch every error the driver might issue. For example ANGLE might let through a complex shader the driver rejects for some reason. Or, the driver might generate warnings (as some do). So now this problem has turned into somehow keeping a database of the all the drivers out there and what to do when they emit a message so it can then translate it back into this format. That's also assuming that format is consistent even inside a single driver. I have no way to know how to generate every possible message a driver might issue so I can check. Then they need to check every time a new driver comes out that someone didn't change something. Updating the ES spec won't help old drivers or non ES drivers. Then there's buggy drivers. Do they then blacklist any driver that spits out a message that doesn't parse by whatever rules were written previously? Because otherwise if they let any bad messages through someone's spec compliant parsing code will fail and their webpage will stop working. Updating the ES spec also doesn't help with DirectX
I'm neither over nor underestimating the problem. In fact, I refuse to estimate, this isn't about estimation. This is also not about how difficult or easy it is, or soon or late it'll get done, those are all completely utterly irrelevant.

They're completely relevant. There's a finite amount of resources. You have to decide where to spend them. GL hasn't had a standard for error messages for 22 years yet somehow it's doing just fine so this certainly doesn't seem like a priority for resources. 

Epic, Id, Crtek, Autodesk, etc haven't been clamoring for this feature in OpenGL so why is it needed in WebGL?

What you're essentially advocating is this: "This seems complex, I don't wanna do it, I know all our users would be happy if we did it, but I say, we'll have-arse it one more time."

I don't know our users would be happy if we did it. Going off stackoverflow I suspect most of them would never know anything existed because most of them can't even be bothered open the _javascript_ console and see if an error was even printed. It's highly unlikely they're going to write error parsers.

And again, YOU'RE THE ONE HALF-ASSiNG IT! You're asking for 13+ teams to waste time on this when you could probably solve your specific issue with 5 lines of JS regexes 

Great way to spend resources dude!


This might ok if you're selling a product, or service, or work at a company anywhere and you have a looming deadline, or whatever. This isn't appropriate if you're talking about a standard. You should never shrink from the responsibility of solving an issue just because it's inconvenient to do so.