JSCocoa used for OpenGL calls

26 views
Skip to first unread message

HalfdanJ

unread,
Aug 7, 2012, 7:15:58 PM8/7/12
to jsc...@googlegroups.com
Hello

Im currently looking at JSCocoa for an experimental app im currently doing where i want to be able to write OpenGL code and live see the result of it. But at the same time i would like to as well be able to interact with the cocoa layer from javascript. So JSCocoa seems like the right pick for it. But i got some questions!

1. Performance, calling c functions (opengl) with BridgeSupport is very slow, so i wrapped the calls in objective-c calls which was much faster. But what would be the fastest way to call OpenGL C functions calls? Any ideas? Compared to mozilla spideweb interacting with c calls I havent been able to get it as fast. I've been comparing calling the same opengl function call (that draws a rectangle on screen) 10.000 times, and SpiderWeb is at least 10x faster doing it. When profiling there is alot of overhead looking up the objective-c selector (of course). Any smart ways of minimizing this for a defined set of functions? Some sort of caching for example (its the same javascript code that is called every frame)

2. Thead safety, i'm currently calling JSCocoa evaulate from a secondary opengl thread. Is this safe? I'm getting some exc_bad_access some times?

Hope somebody with knowledge in JSCococa has some input for this!

Jonas

Patrick Geiller

unread,
Aug 14, 2012, 1:30:05 PM8/14/12
to jsc...@googlegroups.com
> 1. Performance, calling c functions (opengl) with BridgeSupport is very slow, so i wrapped the calls in objective-c calls which was much faster. But what would be the fastest way to call OpenGL C functions calls? Any ideas? Compared to mozilla spideweb interacting with c calls I havent been able to get it as fast. I've been comparing calling the same opengl function call (that draws a rectangle on screen) 10.000 times, and SpiderWeb is at least 10x faster doing it. When profiling there is alot of overhead looking up the objective-c selector (of course). Any smart ways of minimizing this for a defined set of functions? Some sort of caching for example (its the same javascript code that is called every frame)

JSCocoa is not optimized. Each method signature is decoded every time it's called.
Please send me some sample code running too slowly and I'll check it out.


> 2. Thead safety, i'm currently calling JSCocoa evaulate from a secondary opengl thread. Is this safe? I'm getting some exc_bad_access some times?

I haven't done much thread safety testing.
Once again, please send sample code reproducing the problem.

-Patrick

Gus Mueller

unread,
Aug 14, 2012, 2:04:16 PM8/14/12
to jsc...@googlegroups.com
On Aug 7, 2012, at 4:15 PM, HalfdanJ <jo...@halfdanj.dk> wrote:

> 2. Thead safety, i'm currently calling JSCocoa evaulate from a secondary opengl thread. Is this safe? I'm getting some exc_bad_access some times?

Since JSCocoa is built on JavaScriptCore, there are a couple of rules that you'll have to think about from that perspective- mainly that while JSC is thread safe, it is not reentrant.

-gus

--

August 'Gus' Mueller
Flying Meat Inc.
http://flyingmeat.com/

Reply all
Reply to author
Forward
0 new messages