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

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

>> 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
>> others.
> Have you looked at my ACCELERATION_STATUS proposal in my previous email?

Yes - I read it carefully.

> 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 either
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 game)
to not find any problems on any platforms.  When that platform is a very
popular one - then a fix that is specific to that one machine is the only
way out.

The problem is fundamental.  In order to let the application work around a
particular problem on a particular system with sufficient precision (ie
not dumbing-down the application for systems that don't have that problem)
- you have to let the application know something about the hardware.  That
information can either be a lot of separate little queries or one big one.
 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 to
closely approximate the number needed to list all of the bugs and gotcha's
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 can
extract.  They still have glGet results and the ability to time things and
to check what various rendering context requests actually return.  That
adds almost as much information as VENDOR/RENDERER/VERSION for the likes
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 boss
says that this is an important market for us so we need to make it work". 
Using indirect methods to guess that this is a Mk II WonderCorp tablet
have to be good enough to effectively replicate the information in

Look at the number of places where the User-Agent string allows current
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 public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: