One of the coolest things I learned from the original blog post [1] on Ejecta was a trick that the library uses for drawing polygons on the GPU in OpenGL without triangulating them first [2]. It's one of the coolest graphics programming tricks I've ever seen and when I understood how it worked my mind was blown.
With a bit more trickery, you can even implement the Non-Zero fill rule (Canvas2D default), instead of the simpler Even-Odd rule. Ejecta now supports both:
btw do you have any numbers on how bezie drawing using OpenGL compares to regular drawing on 2d canvas, performance wise?
let's say I have an html5 app which draws stuff using 2d canvas. do you think it makes sense to draw to webgl instead using implementation like yours, i.e. mapping 2d canvas api to webgl?
Using stencil buffer to draw polygons without tesselation seems to be one of those folklores that is not widely known. I learned about it some years ago here:
Would be nice to see some benchmarks. I can't see how this could be faster than just running it in Safari. In Safari you get access to far faster javascript jit than you do in the embedded app js engine. The app itself just translates the javascript canvas calls into objc calls to the core graphics.. which is what safari's canvas does anyway? Is the extra level of indirection through safari enough to compensate for slower jit? Plus it's a lot harder to compile this than it is to put a js game on the web.
Needs benchmarks to be able to make any decisions.
Ejecta uses OpenGL ES 2 for Canvas, not Core Graphics.
The default demo that comes with Ejecta[1] runs with 60fps on the iPhone4S. Just try it in Mobile Safari. Even Desktop Browsers struggle with this. Of course it's a contrived benchmark, but it still makes a point, I think :)
There are also a lot of other reason to use Ejecta. If you _want_ to distribute your App in the AppStore, the alternative is to use a WebView framework such as PhoneGap, which can't use JIT either. That said, the raw JavaScript performance is rarely the bottleneck for games - most of the time, drawing is.
Ejecta seems to use OpenGL to implement canvas. WebKit (thus Safari) does not do that, and there is significant performance gap there.
Company 100, Inc. maintains a patch to WebKit that use OpenGL to implement canvas. It is not yet merged, but I have tried it and it is significantly faster than stock WebKit for game scenario. So I have no trouble believing Ejecta is faster.
If you're doing WebGL stuff, I would encourage you to get the current Ejecta dev version from Github, instead of the last release version. There have been a lot of WebGL related bugfixes since: https://github.com/phoboslab/Ejecta
Ejecta is awesome. So is ImpactJS. Dominic (the creator) is experimenting with making Ejecta cross-platform so hopefully we will see an Android version soon.
The JavaScriptCore API is private on iOS,
which means you're not allowed to link to it.
Ejecta therefore comes bundled with its
own version of the library to circumvent these
restrictions.
So you are basically using another VM(a second javascript core) in an IOS app. Isnt it forbidden to do so,running VMs in IOS apps?
A better approach would be to do like TITANIUM ,except that you expose a CANVAS like API,so that your javascript canvas framework is compatible with it => less work,and no trick that would make your app kicked out of the store once the scheme is busted.
Apple used to forbid bundling interpreters/VMs, but the rules were relaxed in 2010, to forbid only dynamically loading code to execute in such an environment. A code-executing environment where all the code to be executed is statically bundled with the app is allowed since 2010, so you can embed a Lua or JS environment as long as you also embed all the Lua/JS scripts in the app.
3.3.2: An Application may not download or install executable code. Interpreted code may only be used in an Application if all scripts, code and interpreters are packaged in the Application and not downloaded. The only exception to the foregoing is scripts and code downloaded and run by Apple's built-in WebKit framework.
No, it isn't. It would make the likes of Xamarin and RubyMotion impossible. You're confused with the fact that App Store policies do not allow downloading and running new executable code.
v8 also doesn't have an interpreter mode, just a compiler. On iOS you can't allocate writable+executable memory, so you can't use v8.
As I mentioned in another thread, I currently have a toy project that implements most of the Canvas2D API in plain C. Maybe this will amount to something some day.
[1]: http://phoboslab.org/log/2012/09/ejecta
[2]: http://www.glprogramming.com/red/chapter14.html#name13