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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification

On Thu, Jan 8, 2015 at 11:13 PM, Florian Bösch <pyalot@gmail.com> wrote:
We don't agree at all. I've got nothing "against" using whatever duct-tape and chickenwire is required to gap this problem, that's what I, and everybody else, is doing anyway. That's not a suggestion of how to solve this issue, this is a description of the status quo. That's what we do. I didn't come here to talk about chickenwire and duct-tape. Not at all.

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. 

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.

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.


What I point is that there is half a specification, this half specification, specifies delivery of line-numbers and file-numbers to the ESSL compiler (the #line directive). What I also point is that, this feature is specifically intended to ease debugging of shaders, that's how it's used by everybody. And finally, I point out how the return values of that API, which is both in theory and practice intended for machine consumption, is not standardized. And so conclude how this lack of agreement of the format is already an annoyance (because one vendor doesn't agree on the format and you've got to add some duct-tape and chickenwire to make it work), but that worse than that sometimes you get back completely unusable error message (which should obviously be fixed) and how both of these problems will not get any better in the future if there isn't a consensus reached. And the consensus is very simple:

Error info log messages are part of the API, intended for machine consumption.

This isn't a difficult realization to agree on, at all. It doesn't require 50+ messages. It's exceedingly obvious to anybody. And it's a complete mystery to me why I even have to talk about it.

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