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.