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

[Chris Marrin]

On Jan 6, 2011, at 12:27 PM, Dmitri Rubinstein wrote:

> 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.

Sorry, I didn't mean to start a ray-tracing flame war. But I guess I did put the bait out there. So I won't respond, not because I don't think your comments are worthy. I just don't think this is the thread for it. Once again, sorry.

> 
>>> 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 ?

Again, I don't want to argue about how 3D should be included in a browser. From my point of view the way to proceed is with simplicity and low expectations. I don't necessarily think that's the best way. But from my recent experience as a WebKit developer, it is the path of least resistance. It seems that there is a lot of energy here, which is great! But I think I've stated my position enough. Continuing would just be carping on my part.

-----
~Chris
chris at marrin.com