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

Re: [Public WebGL] WebGLSL Media Type Proposal

Maybe I wasn't clear, but what I meant by using script tags was something akin to this:
<script id="shader-vs" type="x-shader/x-vertex">
  attribute vec2 aPosition;
  attribute vec2 aTexCoord;
  varying vec2 vTexCoord;

  void main(void) {
    vTexCoord = aTexCoord;
    gl_Position = vec4(aPosition, 0.0, 1.0);

This may not be JS-interpreted code, but it is GLSL code. It would be nice to be able to pass this element (or similar) to shaderSource().

For smaller demos, it's much nicer to keep the GLSL code along side the WebGL code, since they're pretty tightly entwined because of attrib arrays and uniforms. For larger or more complicated apps, it's clear that separation is preferrable. However, for my simple ping-pong framebuffer-texture implementation of Conway's Life, if I had a file for each shader, it would need an extra four files, each of which contain only a handful of lines. (Not to mention the requirement of a local http server, which most definitely negatively impacts the pick-up-and-hack capabilities of WebGL)


----- Original Message -----
From: "Florian Bösch" <pyalot@gmail.com>
To: "Thor Harald Johansen" <thj@thj.no>
Cc: "public webgl" <public_webgl@khronos.org>
Sent: Sunday, May 20, 2012 9:43:30 AM
Subject: 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="myshader.whatever" onload="console.log(this.response)"/> 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. 

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl