Pender Android for Phonegap Cordova

> To echo your points, the DOM is most certainly an advantage when it comes to layout and the breadth of api's available. However, it kills rendering speed even when hardware acceleration is implemented in the browser.

I disagree! Some of our best performance results on mobile are using Chrome for Android with WebGL enabled (see scirra.com/blog/107/boosting-mobile-html5-game-performance-with-webgl). Basically, although our engine uses lots of browser-level APIs, we don't ever really touch the DOM per-frame. So we don't get any perf hit from DOM manipulation or re-flow. And browsers, especially Chrome, are extremely efficient under these circumstances.

In fact, it is very difficult for DOM-less engines to match the performance of Chrome with WebGL support: unless you re-invent their multi-threaded renderer model which works with WebGL, have a highly optimised pipeline such as being able to read typed arrays from the javascript engine without copying or converting them, and so on, it's likely Chrome will still beat the DOM-less engine performance-wise. Unless you re-invent loads of browser features, Chrome will still beat the DOM-less engine feature-wise. Why re-invent the wheel when you can just use the Chrome browser engine? This is why I'm convinced the future of HTML5 game wrappers on mobile is the Chromium mobile ports.

Ashley

Chrome is hot stuff, and we have members of our team exploring that as well.

Browser reflow can be handled well in an engine like Construct2, but Browser reflow is hard to control outside of a highly controlled environment like an engine such as Construct2. Even accessing DOM element size will trigger reflow. Efficiency of reflow doesn't matter if it's robbing your render loop of resources. AppMobi's DirectCanvas achieved all of it's performance gains purely through stripping a custom webkit Canvas element of its reflow processing. What should have been efficient and negligible gave them a 400% increase in rendering speed.

In fact, it is very difficult for DOM-less engines to match the performance of Chrome with WebGL support: unless you re-invent their multi-threaded renderer model which works with WebGL, have a highly optimised pipeline such as being able to read typed arrays from the javascript engine without copying or converting them, and so on, i

and we do! I'd love to go over Pender architecture with you, but these elements are not as difficult to implement as you make them sound. Any renderer pipeline worth its salt is multi-threaded, and the Pender Renderer is indeed based on an asynchronous rendering model. Our renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it. We can indeed read typed arrays to and from javascript with the embedded js engine api's we use. In fact, we do so in a manner almost identical to chrome in the first place: V8.

I think you seriously underestimate the potential of a DOM-less js rendering engine built like Pender, but I will admit you make salient points:

• With Construct2, you handle the DOM reflow well. This may not be the case with games made with PhoneGap, which is what inspired Pender
• Chrome may indeed be the future of HTML5 Game Wrappers

But let's keep an open mind:

• Pender allows easy exposure of native api's. In fact, in the android prototype mode, you can inject any native api into the js environment with an include like syntax
• wrapping native api's to conform to open standards is also trivial
• the goal of this project is to close the gap between Native and Browser rendering performance. While Chrome offers excellent performance on mobile, it still can't compete with raw native implementations. Pender exists in between browsers and native.

I've been a big fan of construct2 and your blog, Ashley, you've done some really awesome performance breakdowns of the major browsers, platforms and performance.

Currently, I'm working on releasing the V8 version of Pender-Android and Pender-iOS (yes, v8 on ios is possible!) into the wild. Once that's up, I would really appreciate if you would put Pender through it's paces, or point me in the right direction!

Appreciate the feedback!

• Lorin

Thanks. Depending on what technologies were available when the game i'm working was done. I was either going to look at GameClosure and work with there Barista layer to add the controller/IAP. However, working directly with source will probably be easier.

I kind of had a inkling that Pender was related to downtown Vancouver. With Pender and Cordova running parallel through downtown core. The naming convention seemed strange. I also had no idea that PhoneGap had it's early starting point at home :P Love seeing local developers :P

Here is another question. Canvas has a limited fillrate capabilities. So overdrawing over the same place wastes fillrate. OpenGl has better rendering methods and overall better performance. So why is that most developers who are building these JS/WEB bridges are focusing on Canvas rather than focusing on creating a OpenGL layer shim bridge instead. is it really that more difficult to overwrite the Canvas2D with a replacement OGL/WebGL layer that has all the same functions as Canvas2D?

Yeah man, Nitobi, creators of PhoneGap, were founded in Vancouver! The naming convention is an interesting (and embarrassing) story. I tell you this only because you're a Vancouverite. We had a cool (and clever) name for the open source version of PhoneGap after the Adobe acquisition, but failed to reserve rights to the domain *after* we announced the rename :P

We had to go through *another* rename, and since PhoneGap was invented while the office was on Cordova street...

Then Pender came about, and we saw an opportunity for a trend.

On Canvas: yes, excellent points, and to understand, we need to delve into what Pender actually is. We don't overwrite any browser Canvas functions, we implement a custom Canvas API and expose that to the javascript engine. A given chunk of javacode doesn't know the difference: it can consume the Pender Canvas api just as it would a browser Canvas api. However, our canvas api is actually a paper-thin layer between JavaScript and OpenGL ES 2.0! This provides precisely the performance you guess is possible.

It's also true that many other projects like Pender don't do this, and this could be for a couple of reasons. Foremost being that writing a shim is easier than writing a rendering engine in OpenGL and figuring out a way of injecting it into a javascript runtime.

As to Chrome/Chromium: yes, you can clone, rip, change and otherwise hack chromium and distribute it with your app. It inflates the app distrib size, but whatever :). In fact AppMobi got their performance gains with a custom Canvas element that they stripped of DOM reflow processing!

AppMobi's DirectCanvas achieved all of it's performance gains purely through stripping a custom webkit Canvas element of its reflow processing.

Not really - it got its main performance gains by using GPU acceleration, since all they had to beat was the hideously slow software-rendered UIWebViews which didn't even use the GPU! That's how they got their advertised 5-10x speedup, which is about how much GPU rendering beats software rendering by.

My point about reflow is: the Construct 2 engine should never incur a reflow, except when you resize the window, therefore reflow is not important to the performance of Construct 2 games.

ur renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it.

I'm not sure why you say this, because WebGL basically is OpenGL ES 2.0. It's got some minor tweaks for it to work better on the web, but it's basically the same API. The fact our engine's WebGL renderer effectively makes OpenGL ES 2.0 calls directly means you can get a decent performance boost over canvas 2D, since it's skipping all the CPU work done by the canvas 2D layer, which can make it up to twice as fast. So supporting WebGL would be a good step for Pender.

rapping native api's to conform to open standards is also trivial

Really? If you take a look through the Web Audio API specification, is that really trivial to implement in native? Besides, why go to all the work of painstakingly re-implementing all sorts of web standards when it's already been done in Chromium, which is free for you to use?

I could give Pender a shot, but I'm sure it will run in to all the same problems we have with other DOM-less engines. The compatibility is just a nightmare. However if you come up with a Chromium-based wrapper that would definitely be exciting and I'd want to investigate closely!

Ashley

Ok, lost my reply twice now :)

Not really - it got its main performance gains by using GPU acceleration, since all they had to beat was the hideously slow software-rendered UIWebViews which didn't even use the GPU! That's how they got their advertised 5-10x speedup, which is about how much GPU rendering beats software rendering by.

The original DirectCanvas was a hack of the Webkit canvas element, and was released as a code dump about a year ago here: github.com/appMobi. it looks like the repo has since disappeared, likely related to their acquisition.

My point about reflow is: the Construct 2 engine should never incur a reflow

true, Pender?s use case is primarily to run independently, or paired with PhoneGap, in which case reflow is an issue. It would not provide Construct2 with any additional advantage where reflow is concerned.

Our renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it.

I'm not sure why you say this, because WebGL basically is OpenGL ES 2.0. It's got some minor tweaks for it to work better on the web, but it's basically the same API.

There are some function silhouette differences, such as when requesting gpu vbo?s and such, but yes they are basically the same API. But that doesn?t mean they are the same implementation of the API. OpenGL ES is implemented with a driver in the device os kernel. WebGL calls that API. Pender architecture flattens out the number of intervening api calls, and attempts to make performance gains there. I?m working on publishing results from my test framework, and will notify when I can post some hard data.

So supporting WebGL would be a good step for Pender.

yes! WebGL support is part of our roadmap.

Really? If you take a look through the Web Audio API specification, is that really trivial to implement in native?

Exposing a native api to pender is trivial.

Implementation an api (such as Web Audio) from scratch? Non trivial.

Implementing a thin wrapper around the analogous native audio api?s that already exist, and exposing that to a js runtime? I won?t call my work trivial or easy, but it is not a lot of work.

Besides, why go to all the work of painstakingly re-implementing all sorts of web standards when it's already been done in Chromium, which is free for you to use?

We don?t re-implement, we use the Native libraries where they already exist, and wrap them so that they conform to Web standards. You have identified the horizon of Pender?s usefullness, and that is right here: we wrap API?s to enhance performance. Where there is no performance enhancement, or no performance enhancement needed, we don?t bother.

I could give Pender a shot, but I'm sure it will run in to all the same problems we have with other DOM-less engines. The compatibility is just a nightmare.

Pender is evolving rapidly, and I think you?ll be impressed with the V8 version. Having had experience with existing web game framworks, I won?t deny that compatibility may be a big issue.

However if you come up with a Chromium-based wrapper that would definitely be exciting and I'd want to investigate closely!

This would be a very exciting project, and something I?m going to look into right away!

On a side note, I?ve worked with Chromium before: I?ve got a project called Gelly, which had Chromium rendering a tab into an openGL texture. This allowed an openGL rendering engine to overlay a UI defined by html/css/js onto an openGL rendering context.

A chromium-based wrapper for mobiles initially seems like would be awesome, but what about ios? As far as I've heard, chrome on iOS is actually just a reskinning of the UI Webbview because they aren't allowed by apple to use their own JavaScript compilation methods or such. Is it just because it's a web browser that apple doesn't allow it? But if that's the case, wouldn't any game using chromium basically be a web browser, and potentially rejected as a result? Or do they not care as long as the game stays off the web and only loads local content?

A chromium-based wrapper for mobiles initially seems like would be awesome, but what about ios? As far as I've heard, chrome on iOS is actually just a reskinning of the UI Webbview because they aren't allowed by apple to use their own JavaScript compilation methods or such. Is it just because it's a web browser that apple doesn't allow it? But if that's the case, wouldn't any game using chromium basically be a web browser, and potentially rejected as a result? Or do they not care as long as the game stays off the web and only loads local content?

it's true, iOS has had some licence/architecture issues preventing any third party javascript engines from running in fully optimized mode.

However, a recent developer licence change, which prohibited apps from interpreting code in anything but the webview sandbox or the browser sandbox, has been lifted. This happened maybe six months ago?

Now, I very very recently came across a dude who claims to not only gotten V8 to run on iOS, but actually gotten apps based on this tech into the appstore!

github.com/nguyenduong/V8-iOS

I say "claims", because I haven't had a chance to test any of this myself. Suffice it to say that this is an exciting time for mobile html5 game dev!

Oh sweet, good news. I hope the developer's reports are true!

It's been a very interesting discussion.

As mentioned I'm going want to get an Ouya game up and running. You(Lorin) mentioned that it's easy to implement native API's. I'm assuming you mean other JAVA api's like the Ouya DK. Could you point to a simple sample at what would be involved to do such work. I sorta dropped heavy programming last year in favour of my writing(fiction and RPG's) work and then found C2 as a wonderful alternative to coding games on my own. So I'm very minimalist right now on coding :P So any direction and pointers for the right direction would be awesome.

That's an interesting and cute naming convention, but please oh please do not name anything based on Hastings :D

Oh sweet, good news. I hope the developer's reports are true!

Yes, me too! I've got a rather large workload, currently, but V8 on iOS has been added to the roadmap

It's been a very interesting discussion.

As mentioned I'm going want to get an Ouya game up and running. You(Lorin) mentioned that it's easy to implement native API's. I'm assuming you mean other JAVA api's like the Ouya DK. Could you point to a simple sample at what would be involved to do such work. I sorta dropped heavy programming last year in favour of my writing(fiction and RPG's) work and then found C2 as a wonderful alternative to coding games on my own. So I'm very minimalist right now on coding :P So any direction and pointers for the right direction would be awesome.

That's an interesting and cute naming convention, but please oh please do not name anything based on Hastings :D

In reverse order: Hastings Project...ok, now that you say that, I think it needs to happen :)

To clarify what you want to do: create an API for X (like Ouya controller) and expose it to the Pender JavaScript environment?

The Now

Pender uses Rhino for it's embedded js environment. This allows some fantastic utilities for inclusion of native (Java) code and libraries.

1. Inject a Java API into JavaScript from Native

Easily done, example of syntax here:

github.com/lorinbeer/pender-android/blob/master/src/com/pender/PenderCanvas.java

you'll see the implementation of the Canvas drawImage functions

github.com/lorinbeer/pender-android/blob/master/src/com/pender/renderer/PenderRenderer.java

in setupJS, you can see the simple syntax for injecting a native class into JavaScript. Rhino does the rest. That class can now used to create JavaScript objects, and call native code.

2. Include a Java API's from inside the JavaScript Runtime

Easily done as well, example of syntax here:

github.com/lorinbeer/pender-android/blob/master/assets/penderandroidshim.js]penderandroidshim.js

all you do is initialize a js variable with the "Packages.java.namespace.resolver" syntax. Both native droid libraries and custom java librairies can be included this way.

The Future:

The current version of Pender uses the Rhino engine as it's embedded JS environment. This, as I have mentioned, is being replaced with V8 for superiour performance. V8 requires us to wrap api's we wish to expose in a horribly complex (I'm mean nightmarish, really) template system.

Now, the work I'm doing in VateDroid (initial dump here:

github.com/lorinbeer/vatedroid

addresses this. This will allow for runtime inclusion of native classes even from JavaScript!

I want get more performance my game so i want try this but i dont understand how i use.Does pender work with eclipse ?.If it is possible how do i integrate? Please explain me.