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

Re: [Public WebGL] WebGLSL Media Type Proposal

> The WebGL API only accepts javascript strings as input to compile shaders from which you link programs. Whatever you do, in the end you need a javascript string.

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.

- Because authors would like to debug locally and not being forced to
deploy on a webserver (since XHRs don't work locally)

Ding ding ding, we have a winner. Having mostly developed through a local server for most of my web applications, this hasn't been an issue for me, but my current WebGL project is almost entirely client code. Since I've been using SCRIPT tags, I haven't run into the XHR issue yet. I would have been very annoyed if I had.

> You are not supposed to do that, because any kind of shader source has zero, zip, zilch meaning by itself without a context and an application that drives it.

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.

> XHRs are supported by all browsers by now, it's no longer "optional" in the sense you might want to mean it. It's not even listed at all on "caniuse.com" because there'd be no point. All browsers have it. And even if you'd find some throwback browser that doesn't speak XHRs, they would also not be able to do webgl.

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.

> However often authors massage those texts with a few utility functions before passing them on to WebGL anyway (dsheets does this, I do it, practically almost everybody else who writes non-trivial webgl apps does it). Even if we had mime-type and <shader src="..."> and whatnot, it'd be pretty useless, because we need the string, then massage it, then pass it to the API anyway after transmoglification.

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.

XHRs have one problem: They're meant to be HTTP requests. Using them for the "file protocol" isn't exactly semantically correct.

The SCRIPT element is the type of HTML element that is the closest in semantics to what we want here:
- Contains code
- Not displayed to the user
- Not interpreted as text by search engines
- Sourcable if MIME type is supported

There's no other system for local testing of shader programs right now, unless you're happy with very ugly formatting.

I guess you could use a DIV tag and hide it with CSS, but the semantics for that are even worse than SCRIPT.

It's a shame there isn't a DATA tag, really.


----------------------------------------------------------- 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 -----------------------------------------------------------