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

Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings

----- Original Message -----
> >> Steve explained in an earlier email how ACCELERATION_STATUS may not
> >> be
> >> very useful,
> >
> > Right, I should have read his email more carefully the first time,
> > I've
> > replied to it now. I claim that his particular example is best
> > handled by
> > the WebGL implementation.
> So who will be the organization that pro-actively looks for problems
> like
> the faked vertex-texture support - for EVERY graphics card, every
> CellPhone...with EVERY driver version on EVERY OS and in EVERY browser
> -
> and decides which to fix and which not to fix...and to do this in a
> timely
> manner?

I agree that this is hard, but if the choice is between the browsers and the web applications, it seems clear to me that it's best to let the browsers handle that, as that will enable much better collaboration, for these reasons:

1. there are far fewer browser makers than there are web applications
2. there is good cross-browser collaboration around WebGL already
3. some major browser engines supporting WebGL are open source, further easing collaboration
4. browsers compete against each other to run faster a given web application, so you can trust us to take seriously bugs like "your browser is 2x slower than the competition on this game".
5. browser makers receive plenty of bug reports already (at least Mozilla does), anyway, about a given WebGl app not working on a given graphics card, or being very slow. So we have to handle this stuff anyway.
> That's an immense on-going task requiring a lot of funding.
> What's more, when you do find a problem, how will you ensure that
> every
> end-user gets a browser update?

Browsers update themselves rather frequently anyway (security fixes...). Frequently enough for this use case.

> When an application author finds a bug with a particular setup - he
> can
> probably work around it right then and there and have a new web page
> up
> within hours...but only if he can make the fix happen apply only to
> that
> particular setup.

I understand, but as far as I can see, having to wait for a month for an issue to be fixed in browsers and an update to be deployed is not too bad, especially if you consider that in exchange for that, you get to benefit from fixes found in other web apps too.

> But worse still - to extend the vertex-texture example further:

With the first solution that I proposed, getParameter(VERTEX_TEXTURE_IMAGE_UNITS) would return 0 on said hardware, so you would be able to handle that.

> But the other guy would find that disasterous - he'd much prefer for
> WebGL to do nothing at all.

That's why I proposed my alternative proposal: keep default behavior unchanged, introduce a new hint() parameter or context attribute DONT_WANT_SLOW_FALLBACKS switching to above-described behavior.

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: