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 platforms.
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 <[email protected]> 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
> http://muellerware.org
