[native-client-discuss] filesystem and 3D apis

[Ariel Manzur]

Hi..

my company is developing a 3d game engine that we plan to release as
open source. we have ports to about 6 platforms and I'd love to add a
nacl port. I've been looking at the SDK apis, and the most important
that seem to be missing are 3D and filesystem. are there any plans/
work in progress for them? I'd love to help out.

thanks.

Ariel.

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

[Brad Chen]

Apologies that some of our documentation is out of date.

The production version of Native Client in Chrome will support Open GL ES 2.0. There is a preview emerging in Chrome 5 Beta 3. You can find support today in waterfall builds of Chromium (search for "Chromium Waterfall"), although the developer support side of this is not quite there yet externally.

Filesystems: this will be a pain point for a little while longer, but emerging HTML5-related standards will provide more useful abstractions for using local file storage and we will be quick to adopt that. However, what you _won't_ see from Native Client is magical powers for accessing the namespace of the local file system; that would obviously be a security issue.

Brad

[Ariel Manzur]

On Mon, Apr 26, 2010 at 1:33 PM, Brad Chen <brad...@google.com> wrote:
> Apologies that some of our documentation is out of date.
> The production version of Native Client in Chrome will support Open GL ES
> 2.0. There is a preview emerging in Chrome 5 Beta 3. You can find support
> today in waterfall builds of Chromium (search for "Chromium Waterfall"),
> although the developer support side of this is not quite there yet
> externally.

Does this depend on the browser that is running the plugin? as far as
I know, once the browser hands over the Window/HWND/whatever to the
plugin, we can do whatever we want with it, including getting an
opengl context on it. Isn't that the client's job, instead of the
browser? (especially if there's also a standalone player).
I'll check out that chronium build.. is there any code/demos in
particular that I should be looking at?

> Filesystems: this will be a pain point for a little while longer, but
> emerging HTML5-related standards will provide more useful abstractions for
> using local file storage and we will be quick to adopt that. However, what
> you _won't_ see from Native Client is magical powers for accessing the
> namespace of the local file system; that would obviously be a security
> issue.
> Brad

that's cool, I can probably bundle my own filesystem on the binary for
now.. we don't depend on the fopen/etc apis, so it shouldn't alter my
development.

thanks

Ariel.

[Ian Lewis]

It's true that in a standard NPAPI plugin, you could just munge the HWND (or whatever) as you pleased. You can't do this in Native Client.

There's a simple rule of thumb that I've found helpful for thinking about NaCl's capabilities. For any capability (for instance, creating an ogl context on an HWND), ask yourself these two questions:

1. Is it secure?

2. Is it cross-platform?

In the case of HWND, the answer to both questions is no. Therefore, you can't do it in NaCl. Instead, you need to use the purpose-built NaCl version of GL.

Ian

[Alan Donovan]

> However, what

> you _won't_ see from Native Client is magical powers for accessing the

> namespace of the local file system; that would obviously be a security

> issue.

Is this really off the table indefinitely?  I can imagine many useful generalisations of the current <input type='file'> mechanism, to allow such things as the Picasa photo uploader to be implemented portably as a NaCl module, or for programs to cache temporary state in a restricted R/W portion of the file tree.  Is anyone aware of security-conscious plans to augment the accessibility of the filesystem to web apps?

cheers

alan

[Ian Lewis]

Viktor just pointed out that I completely misunderstood the question. I thought you were asking about using an HWND in Native Client. I see now that you were asking whether OGL in NaCl was dependent on Chromium or not. I'll shut up now. ;-)

Ian

[Victor Khimenko]

On Mon, Apr 26, 2010 at 9:08 PM, Ariel Manzur <pun...@gmail.com> wrote:

On Mon, Apr 26, 2010 at 1:33 PM, Brad Chen <brad...@google.com> wrote:
> Apologies that some of our documentation is out of date.
> The production version of Native Client in Chrome will support Open GL ES
> 2.0. There is a preview emerging in Chrome 5 Beta 3. You can find support
> today in waterfall builds of Chromium (search for "Chromium Waterfall"),
> although the developer support side of this is not quite there yet
> externally.

Does this depend on the browser that is running the plugin?

It depends on the plugin.

 

As far as I know, once the browser hands over the Window/HWND/whatever to the

plugin, we can do whatever we want with it, including getting an
opengl context on it.

Yes, but this scheme falls apart in the browser where plugin works in separate process. To address the issue new plugin API was proposed: https://wiki.mozilla.org/NPAPI:Pepper

It's not implemented in Mozilla yet, so there are no 3D support in Native Client plugin. Of course the plans are to have 3D supported on all platforms where Native Client works, but right now only Chrome has this support.

[Bennet Yee (余仕斌)]

On Mon, Apr 26, 2010 at 10:36 AM, Alan Donovan <adon...@google.com> wrote:

> However, what

> you _won't_ see from Native Client is magical powers for accessing the

> namespace of the local file system; that would obviously be a security

> issue.

Is this really off the table indefinitely?  I can imagine many useful generalisations of the current <input type='file'> mechanism, to allow such things as the Picasa photo uploader to be implemented portably as a NaCl module, or for programs to cache temporary state in a restricted R/W portion of the file tree.  Is anyone aware of security-conscious plans to augment the accessibility of the filesystem to web apps?

one version that's likely to be feasible -- esp given the direction that the standards are moving -- is for a NaCl module to trigger a file picker to pop up.  the file picker will be implemented by the browser (trusted code), and the NaCl module would, assuming that the user picks a file, get an open file descriptor (probably read-only by default, unless additional checkboxes were clicked), possibly plus some metadata such as pathname.  whether there is a way to persist such user authorization choices is still up in the air afaik.  anyway, this looks more like a capability passing model -- NaCl modules can ask for, and be given a capability to access a file, but would not have by itself authority to access the file system at large.

 

cheers

alan

--

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.

--
bennet s yee
i usually don't capitalize due to mild tendonitis

[Victor Khimenko]

It's totally different issue. All extensions to <input type='file'> mechanism will require some explicit action from the user before plugin will have a chance to look on file. Games need transparent access to files in the background and they don't particularly care if the user has access to the data or not (user is not supposed to mess with game saves). For now your best bet is HTML5 local storage. Perhaps in the future some different, more suitable interface will be added to HTML5.

[Alan Donovan]

one version that's likely to be feasible -- esp given the direction that the standards are moving -- is for a NaCl module to trigger a file picker to pop up.  the file picker will be implemented by the browser (trusted code), and the NaCl module would, assuming that the user picks a file, get an open file descriptor (probably read-only by default, unless additional checkboxes were clicked), possibly plus some metadata such as pathname.  whether there is a way to persist such user authorization choices is still up in the air afaik.  anyway, this looks more like a capability passing model -- NaCl modules can ask for, and be given a capability to access a file, but would not have by itself authority to access the file system at large.

This sounds reasonable; do you know of any concrete specifics, e.g. who's working on this problem?  I would hope that they're also considering support for accessing more than one file at once (e.g. a set of photos), and mechanisms for using drag-n-drop from the platforms existing file-viewer applications.

[Victor Khimenko]

Yup. This is what Firefox is doing:

  https://developer.mozilla.org/en/Using_files_from_web_applications

This is area where Chrome is slightly behind. But as I've pointed out even if implemented it'll not be very useful for game assets and saves. You'll probably want to use HTML5 storage: http://www.w3.org/TR/webstorage/

On Mon, Apr 26, 2010 at 9:51 PM, Bennet Yee (余仕斌) <b...@google.com> wrote:

one version that's likely to be feasible -- esp given the direction that the standards are moving -- is for a NaCl module to trigger a file picker to pop up.  the file picker will be implemented by the browser (trusted code), and the NaCl module would, assuming that the user picks a file, get an open file descriptor (probably read-only by default, unless additional checkboxes were clicked), possibly plus some metadata such as pathname.  whether there is a way to persist such user authorization choices is still up in the air afaik.  anyway, this looks more like a capability passing model -- NaCl modules can ask for, and be given a capability to access a file, but would not have by itself authority to access the file system at large.