Re: [Public WebGL] Caching shader compile assembly

[Gregg Tavares (勤) <gman@google.com>]

On Wed, May 2, 2012 at 4:19 PM, Glenn Maynard <glenn@zewt.org> wrote:

On Wed, May 2, 2012 at 6:16 PM, Gregg Tavares (勤) <gman@google.com> wrote:

So, all that happens is if you setTimeout to 1000ms and it takes 1500ms to compile the shader then you'll wait 500ms when you call gl.getProgramParameter

Which isn't very asynchronous. :)

It's "effectively" async as I said in the original post. I know several apps that are compiling 10-20 shaders with a timeout of 1000 for the entire lot and having no blocking whatsoever. 

Honestly, I don't feel adding an async API is a real priority. Caching will solve most of the speed problems. They are mostly dwarfed by downloading then uploading textures and geometry. So on the list of things browser vendors could spend there time on related to WebGL, a new async api for shader complication hardly seems like a priority.

 

(Another idea comes to mind, but I'll start a new thread to stop hijacking this one.)

--
Glenn Maynard