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

Re: [Public WebGL] getShaderInfoLog/getProgramInfoLog format specification

Referring back to the mobile limiting extension idea this again seems far better implemented as a _javascript_ library. Either take ANGLE and compile it with emscripten or write a new parser. There's no reason to bloat the spec and bloat browsers with this stuff.

And just like before, you can continue to add more and more features whenever you want without having to wait for 4, 5 or 6 browser teams to find the time to do it for you. You won't need to argue here about which format should be supported (text, JSON? XML?)  and whether it it be internationalized or which warnings to include vs errors and which other features you want. If you want a feature add it, if you can't agree fork it.

You could even easily expand that into some kind of uber shader debugger that re-wrote/re-compiled the shaders on the fly as you try to step through them.

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

On Wed, Jan 7, 2015 at 3:50 PM, Jeff Gilbert <jgilbert@mozilla.com> wrote:
I am not convinced translation is necessary, or that without translation, the logs are useless. (The reason it has a de facto standard is that everyone but IE use ANGLE)

Further, it's not guaranteed that all errors are caught by ANGLE. Even if we assume ANGLE is perfect, sometimes there are GL implementations that are too strict. These would generate non-standard error logs. We don't want to get involved with translating error logs.

Since it seems the main benefit for devs is having the error line displayed, I recommend requesting this functionality from browser vendors. I think trying to codify a log format just so devs can write parsing translators is the wrong way to go about this.

On Tue, Jan 6, 2015 at 11:43 PM, Florian Bösch <pyalot@gmail.com> wrote:
It's worth noting that similar problems exist with JS'es error.stack, but these are discussed in the es-discuss WG/ML.

This is how the error looks on: Linux Chrome/Firefox, Android Chrome Mobile, OSX Chrome/Firefox/Opera/Safari, iOS Safari, Windows Chrome/Firefox

ERROR: 0:170: 'dot' : no matching overloaded function found
ERROR: 0:178: 'textureEnv' : no matching overloaded function found 
ERROR: 0:174: 'return' : function return is not matching type: 
ERROR: 0:187: 'getShading' : no matching overloaded function found 
ERROR: 0:188: 'getShading' : no matching overloaded function found 
ERROR: 0:186: '=' :  cannot convert from 'const mediump float' to '3-component vector of float'

This is how it looks on Windows IE:

(170, 29): Invalid arguments passed to function 'dot'

There's already nearly a standard, except it's not spelled out, and some don't follow it. And it's perhaps a bit clumsy on style (it'd be preferable to deal with a structured format rather than a blob of text, but whatever).