[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
----- Original Message -----
> On Tue, Nov 30, 2010 at 4:45 PM, Benoit Jacob <email@example.com>
> >> In the case of the example I gave - I don't see how you CAN fix
> >> this
> >> in
> >> WebGL. There are many areas of OpenGL where this problem arises -
> >> I'm
> >> going to continue to use the vertex texture example - but there are
> >> MANY
> >> others.
> > Have you looked at my ACCELERATION_STATUS proposal in my previous
> > email? I had your use case in mind, and was also aware that this
> > would be just one of many others, possibly too many for us to try to
> > handle in the browser implementation, that's why I proposed to
> > settle for a coarser acceleration-status detection. I realize that
> > it wouldn't allow you to tweak your rendering as finely as you could
> > with the RENDERER etc strings, but I argued that this should be
> > enough. What's your opinion on this?
> 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.
> since there are many dimensions of hardware performance.
> If we add status bits for every possible performance measure of
> interest, that would end up supplying the same entropy for user
> fingerprinting that you are trying to avoid by denying a meaningful
> RENDER result.
Right, that's why I attempted a one-dimensional projection of that with my ACCELERATION_STATUS proposal. It may well be that it was useless, given that Steve's example falls IMO into the "handle in WebGL impl" category.
> The other reason not to do this is that vendors will
> get it wrong, like Steve described with the vertex-texture-fetch
The nice thing with handling stuff in the WebGL impl is that we protect app devs from graphics vendors getting it wrong. Or if you mean browser vendors --- ok, fair enough, but it isn't as bad as having all the app developers getting it wrong (there are fewer browser vendors than there are webgl websites).
> In the end, what WebGL app developers are going to want is effectively
> a fingerprint of the user's hardware, for use in setting default
> graphics features. There are workarounds that don't involve RENDERER,
> like we could try to fingerprint the hardware using other queries
> (less reliable, more dependencies), or have each app benchmark each
> user independently (slow).
> My feeling is that the RENDERER string is extremely useful to WebGL
> app devs, and of only slight benefit to people who want to fingerprint
> users (they already have better sources of entropy as highlighted in
> the EFF paper). So I hope we keep a useful RENDERER.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: