[X3D-Public] Fwd: Re: [X3D] X3D HTML5 meeting discussions:Declarative 3D interest group at W3C

[Dmitri Rubinstein]

Chris Marrin schrieb:
> 
> So you're saying that my iPhone can do real-time raytracing? Or my 4 year old ATI graphics card? I've seen nice demos of ray-tracing in a fragment shader, and I know new Nvidia (and presumably ATI) is very powerful and have the potential to do ray-tracing much faster. But that's not mainstream. 

Today, yes real-time ray tracing will not run fast on mobile devices. 
But was OpenGL available on mobile devices 4-5 years ago ? And what do 
you think about this :

http://www.techwatch.co.uk/2010/12/16/imagination-technologies-buys-up-caustic-graphics/

Accordingly to Wikipedia PowerVR MBX chips, produced by Imagination 
Technologies, are used in iPhone. And now this company buys ray tracing 
company.

> 
>> When this is somehow engineering problem, and we also discussing engineering details here (Do we ?), then let me ask you engineering question:
>> Why not add into a browser a more sophisticated plugin API that allows a plugin to provide a native implementation for elements of an arbitrary XML namespace and propagating all events like DOM changes and CSS information into plugin. Combined with direct access to OpenGL's 3D context, and I think this is already available via NPAPI:Pepper, this should be enough to implement scene graph engine without modifying a browser. Then the decision what to support and how 3D DOM should look like is up to the plugin author.
> 
> The single most important aspect of a web browser isn't power or performance or even feature set. It is security. Every browser vendor rails against plugins because it opens the browser to intentional and unintentional security breaches. When discovered, the only recourse the browser has is to send out an update which blacklists the guilty plugin. The user sees his or her web application suddenly stop working because of this and so they blame the browser, not the plugin vendor. 
> 
> Adding a feature like WebGL to the browser is done to add features and performance to be sure. But more importantly, it allows the browser to control the security of that component.
> 
> Allowing plugin access to a bare OpenGL context is another huge security issue. OpenGL was not designed to be hardened against attacks. We are just now working with vendors to add these capabilities. So I don't see any possibility of opening the internal workings of the browser to any 3rd party plugins.

When the security is the major problem, then all NPAPI plugins are 
already huge security holes. Anybody can install unsafe plugin, even 
when it does not access OpenGL, but I understood this always as a 
personal security risc. When browser vendors see plugins as bad thing, 
since people blame browser vendors and not plugin authors then why 
vendors don't deactivate plugins completely ? And why Chromium 
additionally support native client NaCl ? Is this not a security risc ? 
I seen that NaCl use novel sandboxing technique. Does it solves the 
security problem ?

Dmitri