incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lorin Beer <>
Subject Re: Project Pender for inclusion in Cordova-labs
Date Fri, 15 Jun 2012 15:48:43 GMT
gtanner &&  Ken Wallis:
	The targeted version of BB for Pender is 7.0.
	For BB10 and Playbook, Pender just requires a shim to insure even compatibility across all
	That having been said, I will likely write a proof of concept for BB10. Much like iOS 5,
with greatly improved canvas performance, there are still applications for a fast, embedded
js engine. Whether that is project Pender, or just an example project for those interested
in efficient DOM-less js scripting, we can discuss.

Patrick Mueller:
1. I have a few design docs, I can polish those up and share them

2. instead of Phonegap's Native-Webview bridge, we have a JSEngine-Native bridge, supplied
by the api of the JS engine in question. The good news is that it provides much faster communication.
The actual speed 
depends on the platform and the engine being used, but on platforms tested so far, this bridge
provides enough bandwidth to render scenes with impressive frame rates.

3. While JSC can be made to run as an independent embedded engine, at the time of writing
it was judged that the iMonkey project (spidermonkey for iOS) had better support, and therefore
a better chance of working if I ran into serious trouble.
Now, my opinion on Apple's EULA should be taken lightly, as Pender iOS has NOT made it into
the apple store yet. But my understanding is that Apple will only bark if we try to feed the
embedded js interpreter code that is downloaded from the web. As long as the javascript Pender
is executing is baked into the app, everything's kosher.
Dynamic compilation to optimize JS sounds really awesome, but iOS architecture prohibitively
prevents use of JIT or anything like it. Like you suggested Monsieur Mueller, Apple does not
allow memory to be flagged as executable, so user-land code is totally unable to make use
of JIT.

4. the split is about 90/10, with 90% of the code being the Pender Native Implementation.
The JS really just sets up the environment. In Rhino, for example, native android java classes
can be imported, the Android Pender js just consists of some import statements, and a wrapper
around Log.d so it matches console.log. 
uch like phonegap, a Users only necessary exposure to the underlying native code is during
project setup. After that, the users access point is the JavaScript-facing Pender api, supplied
by Native. To the point, users of Pender only ever have to see and write Javascript.

On 2012-06-14, at 6:38 PM, Patrick Mueller wrote:

> On Thu, Jun 14, 2012 at 5:25 PM, Lorin Beer <> wrote:
>> Project Pender provides a hardware accelerated 2D graphics api wit JS
>> hooks for mobile devices. This provides a fast drawing context for
>> platforms that lack hardware accelerated Canvas drawing in the native
>> browser.  Currently supported are Android, iOS, Blackberry and Desktop
>> Browser.
> Sounds very cool, but ... questions.
> 1) any other links to the Pender goo beyond your Github project (thx for
> providing that, btw)?
> 2) the latency to get from native to the web view, or vice versa, is not
> fantastic.  What are the impacts for the Pender APIs?
> 3) embedded JS engine.  Kinda weird using SpiderMonkey for iOS instead of
> JSC, but ... who am I to judge.  Of course, Apple may judge.  Has this
> shipped on the App Store yet?  I'm wondering though if we embedded JSC,
> could we make use of the JIT where maybe we can't with UIWebView (seems
> unlikely, JIT may need "mark this data as code" which maybe you can't do
> from user-land code).
> 4) With the embedded JS engine, I guess you have to split your code between
> the Pender stuff and your normal app stuff.  Seems like potentially a
> confusing aspect for users, but obviously means you get to avoid the native
> bridge latency (point 2).  I'm curious to see how
> -- 
> Patrick Mueller

View raw message