[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] about the VENDOR, RENDERER, and VERSION strings
----- Original Message -----
> >> 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?
> Yes - I read it carefully.
_I_ hadn't read carefully enough your email at that time --- sorry. But since then I've sent a newer reply where I suggest that in the example that you describe, this is something that would be best handled by WebGL implementations (of getParameter(MAX_VERTEX_TEXTURE_IMAGE_UNITS)). What's your opinion on this newer suggestion? If you send me your logic determining whether a card has decently fast support for that feature, I'll happily patch Mozilla to use it, so that on "bad" graphics cards, getParameter(MAX_VERTEX_TEXTURE_IMAGE_UNITS) will return 0; or alternatively seem my suggesting about webgl.hint(DONT_WANT_SLOW_FEATURES) (could also be a context attribute).
> > 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.
> But that's the problem. Coarser is precisely what isn't useful. My
> application needs to know that one very specific thing (whether vertex
> textures are truly supported in hardware or not) in order to apply one
> very specific fix to the algorithm it's using.
> 3D graphics cards and their drivers are horribly complex things - and
> every single one of them - without exception - has some quirk that
> makes it run really slowly under some condition - or some outright bug
> that has to be worked around. I've yet to find one that was perfect!
> Fortunately, most applications don't trip over many of these problems
> but it's rare indeed for any sizeable application (like a decent 3D
> to not find any problems on any platforms. When that platform is a
> popular one - then a fix that is specific to that one machine is the
> way out.
> The problem is fundamental. In order to let the application work
> around a
> particular problem on a particular system with sufficient precision
> not dumbing-down the application for systems that don't have that
> - you have to let the application know something about the hardware.
> information can either be a lot of separate little queries or one big
> But the amount of raw information content that you 'leak' to the
> application has to be roughly the same. The number of unique bits has
> closely approximate the number needed to list all of the bugs and
> out there - and that is roughly the same as the number you need to
> describe all of the different graphics cards and drivers out there.
> That's why the anonymity benefits of removing these strings is
> marginal at
> best. There is still plenty of identifying information that bad guys
> extract. They still have glGet results and the ability to time things
> to check what various rendering context requests actually return. That
> adds almost as much information as VENDOR/RENDERER/VERSION for the
> of Panopticlick to work with.
> > 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?
> I don't think it's enough. At some point you need to say "The Mk II
> WonderCorp tablet has a problem with drawing purple polygons - and my
> says that this is an important market for us so we need to make it
> Using indirect methods to guess that this is a Mk II WonderCorp tablet
> have to be good enough to effectively replicate the information in
> RENDERER and VERSION.
> Look at the number of places where the User-Agent string allows
> application writers to work around issues with Internet Explorer not
> implementing something - or some bug being there in one browser or
> another. Could you replace that with one single metric? Of course not!
> But that's what you're asking WebGL programmers to do.
> -- Steve
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: