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

Re: [Public WebGL] WebGLSL Media Type Proposal



On Sun, May 20, 2012 at 6:23 PM, Thor Harald Johansen <thj@thj.no> wrote:
This is a false dichotomy. _javascript_ strings are not the issue. Having to pass quoted and escaped string _literals_ during initial development is the issue, because it's a plain PITA.
I personally never do that anyway, and I'm not using scripttags. I pack my shaders up into JSONs or binary data arrays and load them that way.
 
I would argue that no data has any meaning without a context and an application to process it, as is the case with the numerous types of embedded content that has no meaning without the required plugin.
One of the core design choices of HTML/DOM is that any kind of resource element you can place in there, has a meaning the browser can handle.
- <img> is displayed
- <audio> is played back
- <video> is played back
- <embedd> is passed to a plugin
- <script> is interpreted
- <link> is interpreted

 
If we make XHRs the recommended method for loading GLSL code, there needs to be a way to load local files without creating security holes.
I think that would be a very good idea. Afaik there might be some obscure chrome flag to enable local XHRs, but I couldn't find it. Why can't we just add that to the developer toolbar setting or as a individual setting for a local file.
 
Passing a string is not the problem. Massaging is fine. Placing code inside quoted string literals is ugly. Having no clean way of loading files into strings without deploying to a server is bad.
I actually develop on my server, I often find that even if I structure it to work locally, effects of network latency often illuminate potential load issues better than local machine working.
 
XHRs have one problem: They're meant to be HTTP requests. Using them for the "file protocol" isn't exactly semantically correct.
They are meant to transfer a resource, any resource, be it text, or with XHR2 also binary. It's semantically 100% correct to use them to load resources, that's what they're made for.
 
The SCRIPT element is the type of HTML element that is the closest in semantics to what we want here:
- Contains code
GLSL is only loosely definable as code, it's more correctly defined as a piece of text.
 
There's no other system for local testing of shader programs right now, unless you're happy with very ugly formatting.
There is another system, but you're right, it doesn't work on the local machine, however, I also don't do ugly formatting, I just don't develop on the local machine and the problem goes away (or, if you must, start a local webserver).
 
It's a shame there isn't a DATA tag, really.
We could introduce an <xhr src="" or something. Reason we haven't is that unless you run JS, it is not of any use anyway, and for JS, we have the XHR interface, so it's a moot exercise.