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

Re: [Public WebGL] Re: Long shader compiles

(I thought I recognized your name.  Apparently we had a short email
exchange about something or other almost exactly a decade ago...)

On Mon, Apr 11, 2011 at 9:40 PM, Steve Baker <steve@sjbaker.org> wrote:
> However, for relatively small games that don't take a week to download
> over HTTP and stand a chance of running on things like netbooks and pads
> - you just have to lower your sights and shoot for something a little
> less grandiose.

With upcoming client-side storage APIs, it's going to be perfectly
reasonable to have web-based games which have gigabytes of data, like
many Steam games.  I don't thnik "you're doing too much with WebGL,
tone it down a little" is a good mindset.  I hope WebGL limitations
will be viewed with the goal of eventually addressing them as it
becomes clearer what people want to use WebGL for, not accepting them
as the ultimate limits of WebGL.

For example, it would make a lot of sense to allow caching compiled
shaders, as some PC games do; it's annoying but bearable if
compilation takes a couple minutes, as long as you only have to do it
once.  If compile time is a limitation for developers, it would be
worth exposing a shader cache extension in the future.  If an async
shader API is needed, that seems like the place to do it.

(Not to suggest that it's time do that now, of course.)

> We should try to understand why looped texture lookups are unreasonably
> slow - but I don't think that's a major concern.  Just unwrap the loop
> yourself for chrissakes.

It's good that there's a workaround, but I don't think "work around
poor compiler performance by doing the compiler's job for it" is a
good thing to encourage.

Glenn Maynard

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