Pender Android for Phonegap Cordova

Discussion and feedback on Construct 2

Post » Thu Mar 21, 2013 1:47 pm

[QUOTE=jayderyu] I've barely looked into Pender, just gandered through some of the files a few weeks ago. However I have a few questions.

1. Pender is mentioned to support PhoneGap. Does this mean that Pender can be independent of PhoneGap? Can I just use Pender files to run C2 game.

2. Would it be difficult to implement the Ouya DevKit controller api and IAP. I'm working on an Ouya game and want to make the most minimal effort in regards to persona programming to get my first game out there.

3. Is there enough to get C2 going now?

4. Why is it called Pender?

@ArcadeEd
That would be fantastic. I dislike dealing with command line these days. i've gotten lazy :P[/QUOTE]

1. Yes, Pender operates as an Android Library. Pender can hook into PhoneGap/Cordova through a plugin, or run all on it's own

2. This is definitely something we should look at, and no, I do not think it would be difficult at all. Exposing new API's to the javascript environment on Pender is surprisingly easy. I haven't tested Pender on the Ouya environment, but this has been added to our roadmap!

3. I'm a committer on the PhoneGap/Cordova open source project as well as the creator/maintainer of Pender. Unfortunately, it's going to be a few days before I can look seriously into C2 support. I can write a shim next week to test my ideas. That might be enough to get @Ashley interested if it's successful

4. The origins of Pender trace back to a company called Nitobi, located in Vancouver BC. We were acquired by Adobe Systems in 2011.
--edit-- sorry, still can't post links!
https://maps.google.com/maps?q=pender+street+vancouver&hl=en&ll=49.280243,-123.105401&spn=0.004241,0.008894&hq=pender+street&hnear=Vancouver,+Greater+Vancouver,+British+Columbia,+Canada&t=m&fll=49.279831,-123.108029&fspn=0.003934,0.008894&layer=c&cbll=49.280794,-123.105914&panoid=vCT8-Jmjb7sN-qWyUw2vGQ&cbp=12,104.91,,0,-2.48&z=17

If you zoom out of Street view, a few blocks up, you'll see Cordova Street, which is the namesake of the Cordova project, the open source backend of PhoneGap.lorinbeer2013-03-21 13:51:28
B
4
Posts: 40
Reputation: 382

Post » Thu Mar 21, 2013 2:10 pm

[QUOTE=lorinbeer]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.[/QUOTE]
I disagree! Some of our best performance results on mobile are using Chrome for Android with WebGL enabled (see this blog post). 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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,468

Post » Thu Mar 21, 2013 4:29 pm

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?
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Thu Mar 21, 2013 11:23 pm

[QUOTE=Ashley]This is why I'm convinced the future of HTML5 game wrappers on mobile is the Chromium mobile ports.[/QUOTE]

Yet, Chrome is the not the default browser and all the wrappers use Android Browser UIWebView. They don't use Chrome at all so far. So no matter what results Chrome might give the wrapper won't have access to Chrome canvas. I've heard Chrome is in the pipeline to replace Android Browser, but that was back in early 2012.

B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Fri Mar 22, 2013 1:45 pm

@jayderyu - I don't mean that - Chromium is open source, so you could literally take the code and use it as the engine for a native app, and it would run as well as in the Chrome browser, without using UIWebView, and without needing any other browser installed.
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,468

Post » Fri Mar 22, 2013 6:44 pm

[QUOTE=Ashley] @jayderyu - I don't mean that - Chromium is open source, so you could literally take the code and use it as the engine for a native app, and it would run as well as in the Chrome browser, without using UIWebView, and without needing any other browser installed.[/QUOTE]

damnd, that explains soooooooooo much as to why your constantly talking about using Chromium. Lol, i'm so embarrased :P
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Mon Mar 25, 2013 2:26 pm

[QUOTE=Ashley] [QUOTE=lorinbeer]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.[/QUOTE]
I disagree! Some of our best performance results on mobile are using Chrome for Android with WebGL enabled (see https://www.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.[/QUOTE]

@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
lorinbeer2013-03-25 14:28:26
B
4
Posts: 40
Reputation: 382

Post » Mon Mar 25, 2013 2:37 pm

[QUOTE=jayderyu] 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?[/QUOTE]

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!
B
4
Posts: 40
Reputation: 382

Post » Mon Mar 25, 2013 5:13 pm

[QUOTE=lorinbeer]AppMobi's DirectCanvas achieved all of it's performance gains purely through stripping a custom webkit Canvas element of its reflow processing.[/QUOTE]
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.

[quote]Our renderer is backed by OpenGL ES 2.0 on mobile, and WebGL will have a hard time competing with it.[/QUOTE]
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.

[quote]wrapping native api's to conform to open standards is also trivial[/quote]
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!
Scirra Founder
B
359
S
214
G
72
Posts: 22,946
Reputation: 178,468

Post » Mon Mar 25, 2013 6:28 pm

@Ashley

Ok, lost my reply twice now :)

[QUOTE=Ashley]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.[/QUOTE]

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


[QUOTE=Ashley]My point about reflow is: the Construct 2 engine should never incur a reflow[/QUOTE]

true, Penders 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.

[QUOTE=Ashley]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.[/QUOTE]

There are some function silhouette differences, such as when requesting gpu vbos and such, but yes they are basically the same API. But that doesnt 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. Im working on publishing results from my test framework, and will notify when I can post some hard data.

[QUOTE=Ashley]So supporting WebGL would be a good step for Pender.[/QUOTE]

yes! WebGL support is part of our roadmap.


[QUOTE=Ashley]Really? If you take a look through the Web Audio API specification, is that really trivial to implement in native?[/QUOTE]

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 apis that already exist, and exposing that to a js runtime? I wont call my work trivial or easy, but it is not a lot of work.


[QUOTE=Ashley]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?[/QUOTE]

We dont 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 Penders usefullness, and that is right here: we wrap APIs to enhance performance. Where there is no performance enhancement, or no performance enhancement needed, we dont bother.

[QUOTE=Ashley]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.[/QUOTE]

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

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

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

On a side note, Ive worked with Chromium before: Ive 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.lorinbeer2013-03-25 18:44:13
B
4
Posts: 40
Reputation: 382

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: anty21ro, mystazsea, nimos100 and 10 guests