third-party C++ extensions for o3d

17 views
Skip to first unread message

Marshall Greenblatt

unread,
Sep 21, 2009, 10:32:59 AM9/21/09
to O3D-d...@googlegroups.com
Hi All,

Some tasks, such as 3d shape manipulation and feature recognition, are very computation-intensive.  Implementing these types of algorithms in JS may not be possible or may result in very poor performance. Does o3d currently support the creation of third-party C++ extensions? If not, are there any plans to add this capability?  Specifically, it would be nice if a third-party C++ extension (loaded as a separate binary module, perhaps as part of a Chrome extension) could:

- have full access to all o3d APIs currently exposed via JS
- expose additional JS APIs for use by o3d client applications

Regards,
Marshrall

Ged Wed

unread,
Sep 21, 2009, 11:31:30 AM9/21/09
to o3d-d...@googlegroups.com
could you not use flash or Silverlight for doing CPU intensive calculations and return them back to the JS layer ?

This is what i am using at the moment. The issue of course is having the data inside Silverlight or flash, so you can crunch it.

2009/9/21 Marshall Greenblatt <magree...@gmail.com>

Marshall Greenblatt

unread,
Sep 21, 2009, 12:05:58 PM9/21/09
to o3d-d...@googlegroups.com
On Mon, Sep 21, 2009 at 11:31 AM, Ged Wed <ged...@gmail.com> wrote:
could you not use flash or Silverlight for doing CPU intensive calculations and return them back to the JS layer ?

This is what i am using at the moment. The issue of course is having the data inside Silverlight or flash, so you can crunch it.

Good suggestion, I didn't think of that.  I'll have to test it and see how much latency the JS transfer adds.  Many of the meshes we work with have greater than 100k facets, so I'm thinking the transfer time could prove prohibitive.
 

Ged Wed

unread,
Sep 21, 2009, 12:47:23 PM9/21/09
to o3d-d...@googlegroups.com
Yes exacts the interop across the language boundary is where the benchmarking needs to happen.

i am hoping to start a Google Code project to get it going and see what people are interesting in adding to it further so it can become a generic visualisation engine. I favour Silverlight because there is no much c# code already existing thanks to the XNA frameowork.

what do you think ?

G

2009/9/21 Marshall Greenblatt <magree...@gmail.com>

Salomon

unread,
Sep 21, 2009, 1:00:46 PM9/21/09
to O3D-discuss
You can use Google Gears to make computation-intensive operations in
javascript...

On Sep 21, 4:32 pm, Marshall Greenblatt <magreenbl...@gmail.com>
wrote:

Marshall Greenblatt

unread,
Sep 21, 2009, 1:59:38 PM9/21/09
to o3d-d...@googlegroups.com
On Mon, Sep 21, 2009 at 12:47 PM, Ged Wed <ged...@gmail.com> wrote:
Yes exacts the interop across the language boundary is where the benchmarking needs to happen.

i am hoping to start a Google Code project to get it going and see what people are interesting in adding to it further so it can become a generic visualisation engine. I favour Silverlight because there is no much c# code already existing thanks to the XNA frameowork.

what do you think ?

Well, let's think about this a bit :-).  The difficulty with adding a binary extension capability to an NPAPI plugin like o3d is making it work with existing browser extension/plugin installation procedures and frameworks.  The options that come to mind are:

1. Use the JS communication approach if it provides reasonable performance (I haven't verified that yet for my particular usage case).
2. Add an extension management/installation user interface to o3d. This option would require buy-in from Google developers -- can any Google developers comment on whether an extension concept would fit with the o3d strategic vision?
3. Build a customized version of o3d. This option provides the most flexibility for specific usage cases but has the obvious drawback of compatibility and support headaches.

#1 is probably the most useful and least painful option currently available to the majority of o3d users, so let's consider how we can implement it.  We could use Flash or Silverlight, which are great Web development tools in their own right, but I'm not sure they're the best choice in this particular case for a variety of reasons:

1. We'd be requiring yet another development tool.
2. There are lots of Flash and Silverlight versions out there, and the currently installed version is a factor that we have no direct control over.
3. Support for binary extensions across multiple operating systems could be problematic.
4. It runs counter to the argument that O3d is a replacement for Flash and Silverlight ;-).

I think, therefore, that the best solution for option #1 might be a custom-built NPAPI plugin that can then communicate with o3d via JS.  We can make this option very easy and attractive by developing an open source cross-platform framework that provides the necessary NPAPI glue and build configuration tools. If done properly the tools will be free, the build process will be painless and the version control will be simplified by using existing browser plugin installation capabilities. The user would implement a class providing their usage-specific logic, build the extension for whatever browsers and operating systems interest them, and then make the plugin available for download and installation by their clients.
 

Ged Wed

unread,
Sep 21, 2009, 2:10:54 PM9/21/09
to o3d-d...@googlegroups.com
I agree that Flash / Silverlight sucks as a long term solution and that a pure NPAPI  architecture is best.

I have never developed an MPAPI plug-in and so cant comment about the difficulty factor, but i can aks many annoying question such as:
1. How do you write an NPAPI plug-in that will run on all operating systems. Assuming that its not talking to the GPU etc. Its just purely for doing CPU number crunch.

Now regarding the google gears approach. Yes this sounds great, especially for storing large scenes locally, and no having them download every time. A simple manifest version check being enough to know if the local DB needs to be updated. But it does not at all help in the computational number crunching, unless you like to write this type of code in SQL, which seems mad to me - no offence if i have missed the point please correct me.
Again, i think its great for storing meshes off-line for super fast loading.

Please add more info so eveyone can see if NPAPI is a viable solution within the reach of the devs !!

Marshall Greenblatt

unread,
Sep 21, 2009, 2:39:16 PM9/21/09
to o3d-d...@googlegroups.com
On Mon, Sep 21, 2009 at 2:10 PM, Ged Wed <ged...@gmail.com> wrote:
I agree that Flash / Silverlight sucks as a long term solution and that a pure NPAPI  architecture is best.

I have never developed an MPAPI plug-in and so cant comment about the difficulty factor, but i can aks many annoying question such as:
1. How do you write an NPAPI plug-in that will run on all operating systems. Assuming that its not talking to the GPU etc. Its just purely for doing CPU number crunch.

NPAPI (which stands for Netscape Plugin API) is a cross-browser cross-os standard for developing browser plugins. The authoritative documentation for NPAPI is hosted, appropriately enough, by Mozilla: https://developer.mozilla.org/en/Gecko_Plugin_API_Reference

Provided you use ANSI C and/or C++, the same NPAPI code should compile and build on most operating systems and run in most major browsers.  This list includes Mozilla, Safari, Opera, Konquerer and Google Chrome.  Similarly, most major browsers provide some method for installing and managing extensions that include binary components targeting multiple os platforms.

So, what's the catch?  Mainly that each browser has a slightly different way of packaging extensions (and the minor fact that IE uses ActiveX instead of NPAPI :-).  This is where the proposed framework provides value -- by abstracting away the browser- and os- specific details so that the user need only implement a few classes and execute the "build" command.

For our purposes the NPAPI plugin (or ActiveX control) only needs to support a small subset of the total available NPAPI/ActiveX functionality.  Namely:

1. Some way to export JS objects to the DOM
2. Some way to import/access JS objects from the DOM

It should also be possible to call the o3d JS methods "directly" (via NPObject/NPClass) from the plugin C++ code, which may or may not provide a performance benefit.

Marshall Greenblatt

unread,
Sep 21, 2009, 7:46:30 PM9/21/09
to o3d-d...@googlegroups.com
A good starting point could be this project: http://code.google.com/p/nativeclient/

Ged Wed

unread,
Sep 21, 2009, 8:14:13 PM9/21/09
to o3d-d...@googlegroups.com
Good find.

I remember reading that Google OS will utilise this layer in order to "speed up" web apps. So your approach is likely to be a good base that is future proofed.
The solution with IE is probably to just do all the code in Js, and let IE users just have a poorer experience.

So does anyone knwo if o3d with NPAPI has been done in any open source projects is the question ?
And if not, irs a good idea to start one off i think ? 
Can people interested in this join the thread.

G

2009/9/22 Marshall Greenblatt <magree...@gmail.com>

Ged Wed

unread,
Sep 21, 2009, 8:20:05 PM9/21/09
to o3d-d...@googlegroups.com
I also want to add this. o3d is not the only game in town for openGL base web apps.
The Kronos group has now accepted webGL as a standard, and its now (this week) in the webkit source code.
Chromium is based on web kit, and so are other browsers.

So, the question is can NPAPI be used on top of web kit ?
if so then it allow webGL to also be used.

i have played around with webGl and the JS is very simple and there is alot more control for the developer. By this i mean that the o3d code tend to abstract the control away, but with webGL its all there. Hence that also means that webGL woudl benefit significantly by having a "offload engine" such as NPAPI.

G

2009/9/22 Ged Wed <ged...@gmail.com>

Ged Wed

unread,
Sep 21, 2009, 8:21:27 PM9/21/09
to o3d-d...@googlegroups.com
Yep i just answered my own question.
And this was many years ago

Ged Wed

unread,
Sep 21, 2009, 8:29:42 PM9/21/09
to o3d-d...@googlegroups.com
and Apple employee has implemented webGL in WebKit now !
https://lists.webkit.org/pipermail/webkit-dev/2009-August/009375.html

Niel Drummond

unread,
Sep 22, 2009, 3:27:34 AM9/22/09
to o3d-d...@googlegroups.com
Hi,

I suspect google gears and native client will somehow merge somewhat -
in some of the Google I/O talks they mentioned 'embedding' nativeclient
calls in HTML5 worker threads, which are also implemented in google
gears as a plugin, and therefore presumably also work on the most common
browsers once installed.

What we need is not an "extensions" API, but bindings between these
plugins (potentially distributed as a package of plugins), or simply
some more examples. I could imagine that it is already possible to use
worker threads using the javascript API as a communication protocol
(though I have not tried).

Also OpenGL is implemented in other plugins, e.g. unity3D, though they
are not open source and are perhaps limited in their browser support.

- Niel

Ged Wed wrote:
> and Apple employee has implemented webGL in WebKit now !
> https://lists.webkit.org/pipermail/webkit-dev/2009-August/009375.html
>
> G
>
> 2009/9/22 Ged Wed <ged...@gmail.com <mailto:ged...@gmail.com>>
>
> Yep i just answered my own question.
> And this was many years ago
>
> http://lists.apple.com/archives/Webkitsdk-dev/2007/Nov/msg00035.html
>
>
> 2009/9/22 Ged Wed <ged...@gmail.com <mailto:ged...@gmail.com>>
>
> I also want to add this. o3d is not the only game in town for
> openGL base web apps.
> The Kronos group has now accepted webGL as a standard, and its
> now (this week) in the webkit source code.
> Chromium is based on web kit, and so are other browsers.
>
> So, the question is can NPAPI be used on top of web kit ?
> if so then it allow webGL to also be used.
>
> i have played around with webGl and the JS is very simple and
> there is alot more control for the developer. By this i mean
> that the o3d code tend to abstract the control away, but with
> webGL its all there. Hence that also means that webGL woudl
> benefit significantly by having a "offload engine" such as NPAPI.
>
> G
>
> 2009/9/22 Ged Wed <ged...@gmail.com <mailto:ged...@gmail.com>>
>
> Good find.
>
> I remember reading that Google OS will utilise this layer
> in order to "speed up" web apps. So your approach is
> likely to be a good base that is future proofed.
> The solution with IE is probably to just do all the code
> in Js, and let IE users just have a poorer experience.
>
> So does anyone knwo if o3d with NPAPI has been done in any
> open source projects is the question ?
> And if not, irs a good idea to start one off i think ?
> Can people interested in this join the thread.
>
> G
>
> 2009/9/22 Marshall Greenblatt <magree...@gmail.com
> <mailto:magree...@gmail.com>>
>
> A good starting point could be this project:
> http://code.google.com/p/nativeclient/
>
>
> On Mon, Sep 21, 2009 at 2:39 PM, Marshall Greenblatt
> <magree...@gmail.com
> <mailto:magree...@gmail.com>>
>
> On Mon, Sep 21, 2009 at 12:47 PM, Ged Wed
> <ged...@gmail.com
> <mailto:magree...@gmail.com>>
>
> On Mon, Sep 21, 2009 at 11:31 AM,
> Ged Wed <ged...@gmail.com
> <mailto:ged...@gmail.com>> wrote:
>
> could you not use flash
> or Silverlight for doing CPU
> intensive calculations and
> return them back to the JS layer ?
>
> This is what i am using at the
> moment. The issue of course is
> having the data
> inside Silverlight or flash,
> so you can crunch it.
>
>
> Good suggestion, I didn't think of
> that. I'll have to test it and
> see how much latency the JS
> transfer adds. Many of the meshes
> we work with have greater than
> 100k facets, so I'm thinking the
> transfer time could prove prohibitive.
>
>
>
> 2009/9/21 Marshall Greenblatt
> <magree...@gmail.com
> <mailto:magree...@gmail.com>>

aermartin

unread,
Sep 22, 2009, 12:22:28 PM9/22/09
to O3D-discuss
I would love too see this kinda plugin for the webcam/camera working
with o3d
http://www.youtube.com/watch?v=Y9HMn6bd-v8
Reply all
Reply to author
Forward
0 new messages