Hardware accelarated OpenGL ES 2.0?

[Attila]

I've seen this in the issues:

Issue 132: Open GL for Native Client ‹ Prev 25 of 50 Next ›

Reported by nativeclient.admin, Nov 19, 2009
Chrome 3D should export a Open GL 2.0 ES interface to Native Client.
This is
for Chrome only, Windows, Linux and MacOS.

Does this mean that hardware accelerated OpenGL will be supported in
the near future?
It would be great. ES 2.0 could be a great choice because it is much
cleaner/leaner than OGL.
O3D looks nice, but an intermediate API is much more flexible and
easier to port to.
Will/Could this be supported in other browsers?

Thx

[Brad Chen]

Very good questions. I think we mentioned something about Open GL support at Google IO, an we are very happy that we are making progress on that goal. Please keep watching http://code.google.com/p/nativeclient as well as chromium.org for evidence of our progress.

We are planning to provide Open GL ES 2.0 bindings. I am interested in feedback from the community about whether this is a good match for what app developers would like to see.

Because Open GL support requires significant additional trusted code incorporated into the browser, it's difficult to support in Native Client using our current plugin architecture. We think we can provide excellent support with both GL and Native Client built directly into the browser, and that's why you'll be seeing this feature in Chrome and ChromeFrame first. We would very much like to provide similar support in other browsers as well, but as we are not very keen on delivering it as a plugin, we are encouraging other browsers to support these systems in a more direct way, and investing a lot of effort into issues they have with the system. You can help our cause by planning and writing great Native Client applications, and by encouraging your favorite browser vendor to help us deliver Native Client in their browser.

Brad Chen

--

You received this message because you are subscribed to the Google Groups "Native Client Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

[Attila]

As one app(game) developer I think OpenGL ES 2.0 is a good choice.

Today I've read about this: http://www.khronos.org/webgl/
So it seems OpenGL ES 2.0 will be usable from JavaScript in several
browsers.
I hope that will help OpenGL ES 2.0 support for NaCl in other
browsers.

Great Native Client applications would really help to spread NaCl. I
think
there are many c/c++ developers who could create great application for
the web.
The largest blocker now (i think) is that the current tools to create
applications
are far from ideal. For all platforms I worked on (Win, Mac/Iphone,
several consoles)
there is a good IDE/debugger. Any plans on this?

Regards

[Brad Chen]

We definitely want to have great debuggers but we will invest in finishing and stabilizing the core of the system first. If you have background in developing IDE support, consider contributing to the project, or do a NaCl IDE independently.

Brad

[jd]

To speed things up a bit, why not just make the Transgaming engine
available in native client as is. It's a software rasterizer, so
there shouldn't be a need to add additional trusted code to support
it. Just a simple recompile with the native client libs. Then we'll
have something to work with while all the hardware stuff is getting
ironed out.

Better yet, given the amount of effort that is going into supporting
the hardware directly, why not just admit defeat and ditch it? We
already have a fantastic software raterizer licensed and in hand for
O3D, use it!

From a native client/sandbox security standpoint, what I'm talking
about is 10x easier to validate.

On Dec 2, 10:23 pm, Brad Chen <bradc...@google.com> wrote:
> Very good questions. I think we mentioned something about Open GL support at
> Google IO, an we are very happy that we are making progress on that goal.

> Please keep watchinghttp://code.google.com/p/nativeclientas well as

> > native-client-di...@googlegroups.com<native-client-discuss%2B­unsub...@googlegroups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/group/native-client-discuss?hl=en.- Hide quoted text -
>
> - Show quoted text -

[Brad Chen]

This sounds like an excellent idea, but not the kind of thing we would staff internally at this time, as we are focused on core infrastructure. Assuming it is open source, Transgaming port as an untrusted module would be a very welcome contribution if anybody is interested in working on it.

If Transgaming is not open source then obviously they would have to do the port themselves.

Brad

To unsubscribe from this group, send email to native-client-di...@googlegroups.com.

[jd]

How about Google purchases Transgaming, and then open sources their
rasterizer on native client. Then there wouldn't be a need to staff
internally, just utilize the Transgaming talent. Short and simple,
with a lot of bang for the buck. The resulting market share increase
in Chrome users due to the better looking 3D content would drive up
Google Ad revenue. Chrome would become the #1 browser!

O3D and WebGL are bogged down in quicksand, let's got for the easy
win :)

> > > Please keep watchinghttp://code.google.com/p/nativeclientaswell as