Thoughts on Pepper

Robert O'Callahan robert at ocallahan.org
Mon May 3 14:43:04 PDT 2010


On Sat, May 1, 2010 at 12:01 PM, Brett Wilson <brettw at google.com> wrote:

> One is where Pepper is providing a C-specific or an efficient
> out-of-process
> interface into an API that is otherwise designed for in-process JS.
> This makes sense to have the same rules, but a different "frontend"
> API for the code to interact with.


I can see that if you need to run the native code in its own process (that
requirement is imposed by the design of Native Client, correct?), that
constraint might lead to some different decisions than for current
JS-exposed Web APIs.

However, on the JS side people want to access APIs from workers and that
imposes similar constraints.

2D painting: Theoretically we could use a canvas element and the
> plugin would paint to that surface using the existing APIs. In the
> incomplete demo I'm currently hacking together, I've moved Pepper
> painting much closer to the way Canvas works (I hope to send a
> description of this out next week sometime assuming it works OK). The
> main difference is that we provide a more efficient way to get at the
> pixels and the painting model is designed to be asynchronous with a
> callback. I'm fine with adding this to the Web API if other vendors
> are supportive, but this seems "weird" from the perspective of the JS
> model, at least to me.
>

I'd like to see your proposal, but maybe it won't seem weird from the point
of view of JS accessing a 2D canvas from a worker...


> 3D painting: What pepper exposes is OpenGL ES which is the same as the
> web platform. The way you execute the functions via a command buffer
> rather than specifying individual function calls is slightly different
> so we can send the commands more efficiently across process boundaries
> rather than doing a context switch for each OpenGL call.
>

People also want to access WebGL from workers. I don't see any fundamental
performance issue with exposing a WebGL drawing context to a worker (or
native-code blob with its own thread/process) and having that context
serialize commands to the command buffer. Do you?

Native theming APIs: We've discussed that some clients may want this
> exposed in <canvas> and I don't see any problem with doing that
> instead if other vendors agree.
>

Getting native look and feel right is very hard to do with a cross-platform
API. A 2D canvas API for the drawing part (using CSS3 appearance values)
would be a start, but I actually think in most cases binary code would be
better off constructing DOM content with form controls etc and letting the
browser take care of providing the correct look and feel.

The HTML spec for reading & writing files has a very specific
> definition for how stuff should be written, for example, using
> FileWriter. This is a good interface for JavaScript, but less so for C
> code. We plan on implementing a Posix-like interface for files. You
> would use a special open command that would be provided in Pepper
> which would give you a file handle. Then you could use fread() and
> iostreams like C and C++ programmers are accustomed to. We believe
> this is important for ease-of-use from a C programmer's perspective,
> flexibility when dealing with lower-level primitives like you would
> typically be doing in C, and for porting existing code which we think
> this is a very important part of Pepper.
>

I think we should solve this with libraries. You're going to have to have a
custom libc anyway, so why not ensure FileWriter can implement POSIX-ish
semantics efficiently and then implement your libc on top of it?

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/plugin-futures/attachments/20100504/0207b70d/attachment.html>


More information about the plugin-futures mailing list