oF in HTML5

[ddnn55]

Issue: openFrameworks does not run in the web browser.

Solution: the emscripten backend for the LLVM compiler generates JavaScript, many C++ OpenGL projects have been demonstrated running in the browser with WebGL.

Is anyone interested in this?

[kylemcdonald]

This sounds amazing! How would it work? Do you have any links describing this process? I imagine we'd have to figure out how to run a severely stripped down version of OF so we're only doing OpenGL?

On Jun 9, 2012, at 10:58 AM, David Stolarskyreply@reply.github.com wrote:

Issue: openFrameworks does not run in the web browser.

Solution: the emscripten backend for the LLVM compiler generates JavaScript, many C++ OpenGL projects have been demonstrated running in the browser with WebGL.

Is anyone interested in this?

---

Reply to this email directly or view it on GitHub: https://github.com/openframeworks/openFrameworks/issues/1319

[ddnn55]

Right, camera input for example wouldn't work for free, but you could get it through a Flash webcam bridge, or eventually through HTML5 webcam support. Likewise sockets won't work, but XmlHttpRequest and WebSockets will. Also libs we don't have source for, like Fmod, won't work. But if you have the C++ (or C, or Obj-C, or others), emscripten will convert it to JavaScript, and the switch from OpenGL to WebGL is demonstrated e.g. here: http://www.syntensity.com/static/ammo.html (Bullet Physics demo, it's a big C++ 3D physics engine).

emscripten: https://github.com/kripken/emscripten/wiki

I haven't used emscripten myself yet, but it looks very very healthy on github, and obviously it's really amazing. LLVM is the new compiler Apple is pushing, it replaces parts of or all of GCC, depending on how you use it. It's the default compiler when you use Xcode 4. Basically the LLVM family can compile lots of languages, including the C's, into "LLVM bitcode" and from there, backends can generate native code for x86, or ARM, or whatever, and these crazy people decided to make a JavaScript generator for it.

[kylemcdonald]

that's amazing. we totally need to get on this. i think webgl will definitely be more likely to be adopted in a cross-platform, cross-browser way than any of the chrome nacl stuff. and having OF running on the web would be huge!

[elliotwoods]

there's a demo of a Python runtime ported to JavaScript using emscripten, and also a h264 decoder LLVM byte-code ftw

it seems using the v8(?) engine of chrome it's possible to get machine-code like performance if you code it with specific 'register'-friendly data structures. something like a 20% drop from machine code is possible for some projects.

but this is all a toy and doesn't offer true oF-in-browser support (devices, filesystem, consistent performance) also it has no automated handling of opengl-to-webgl (or specific opengl wrapping at all)

emscripten and equivalents could revolutionise webcode

what would the IDE be like?

is there a reason not to make a native openFrameworks.js? this would also remove the laborious compile-time but would obviously cause issues with syntax / objects

what about native client (that's a pretty easy cross-platform deployment mechanism we could hook right into with likely less hassle than event an iPhone or Android which we've already achieved)

[ddnn55]

right, this would not fully support all of oF. "openFrameworks.js" might be the wrong name. it's more like oF on iPhone, which also does not support arbitrary devices. the IDE is whatever you normally use, the code looks the same, you just compile in a different way, outputting JavaScript and HTML instead of OS-native binaries.

the filesystem (well file reads at least) would become HTTP loads. writes actually could happen too, by just adding a little server-side file write end point (one filesystem, endless number of users, interesting, no?). webcam will work with some glue; overall device support would be no worse than on iOS.

my original motivation is to have a way to write primarily graphical / animation "widgets" in one language/framework and deploy them to web browsers, natively on mobile devices, and natively on desktop platforms. but i think "apps" and "applications" are also viable candidates for this sort of system, and perhaps the web server as the filesystem could be a quite interesting feature to offer oF-land.

i think performance will work itself out as JavaScript and WebGL mature.

[gabrielstuff]

Hi ! I'm a huge fan of javascript. The idea behind running oF in the brower just make me happy. But what are we aiming to ?

A. writing javascript language and use oF API. B. writing C++ language and compile to oF HTML5 app, cross browser (Opera, IE, Firefox, Chrome, Safari, etc..)

It seems @codeboost already made a step in the A path : https://github.com/codeboost/JOpenFrameworks

What would be the benefit ? What would be the limit ? Actually, it seems that : using camera is not a stopper :

• https://developer.mozilla.org/en/DOM/Using_the_Camera_API,
• http://dret.typepad.com/dretblog/2010/04/html5-capture-api.html,
• "This can be done using the NPAPI for most browsers, or by writing a BHO (Browser Helper Object) for Internet Explorer." --> http://stackoverflow.com/questions/4779549/can-i-access-the-webcam-via-a-browser-plugin-add-on

• http://arstechnica.com/business/2012/01/hands-on-building-an-html5-photo-booth-with-chromes-new-webcam-api/

  using sound is perfectly fine. video with canvas is well supported, we even got filter we could use WebGL which is already very vell supported and very nice library use it : three.js finally it seems like a nice path when thinking to Adobe proposal about CSS3 shader ( http://www.adobe.com/devnet/html5/articles/css-shaders.html, https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html )

About performance I totally agree with @gimlids performance will work while JS + WebGL grow up.

Have a nice day !

[ddnn55]

the way i imagine it, this is (B), exporting a normal C++ oF app to HTML5. though perhaps converting oF to .js through emscripten would make it pretty easy to actually provide oF's API to JavaScript coders.

the benefit is (1) opening the web browser to oF developers, but maybe they already know sufficient JavaScript? need to do some market research =) and benefit (2) "write once, run everywhere" for graphical / animated apps. to elaborate on my original motivation -- i want to target native iOS and the web browser at the same time. (and Android and desktop at the same time as well, sure why not)

also i agree, JavaScript is surprisingly delightful, especially once you get into the functional style.

[elliotwoods]

the 'tidy way' is going to be somehow writing an openFrameworks lib that compiles to js and wraps native WebGL calls for graphics. then when you compile you staticly link that lib instead of the oF OpenGL ones

and then a seperate piece of work to expose oF api back to JS for in-browser livecode hacking

[ddnn55]

A little update/bump because today Google/Chromium announced they are forking WebKit --> Blink and making some big, interesting changes, and also emscripten is alive and well, and Mozilla is somehow involved with it. So like, the web, and stuff.

@elliotwoods If I understand you correctly, I think you are suggesting more work than is necessary for this. What emscripten is supposed to mean is that we just write an appropriate Makefile and voila, oF apps can be compiled straight to "HTML5." Only caveats I think are local filesystem access, sockets, things like that. OpenGLES automatically gets mapped to WebGL through the emscripten (and maybe asmjs.org) process, so as long as "HTML5" mode uses OpenGLES calls, as already exist for iOS, that part is taken care of. Maybe C/C++ sockets will be automatically mapped to WebSockets now, or in the future.. not sure on that.

Can anyone think of outstanding reasons a lot more work might have to be done? Poco (I'm not so familiar with it, nor its integration in oF)? FMOD audio comes as a DLL already, so I assume emscripten will not eat it up.

For ofFile, a portion of ofFile (the read part) could be implemented as a URL load, so you just put your app on a web server, and file reads happen over HTTP...

[ddnn55]

https://github.com/kripken/emscripten/wiki/Building-Projects

[arturoc]

i've been trying emscripten, haven't done anything serious yet just tried to compile a couple of c programs and it looks promissing. i want to try to compile OF. i've been looking at google's naci for a while but the fact that it only runs on chrome and that the only way to distribute naci apps is through the chrome store so it makes it way less interesting that it could seem at first.

Once we have gles2 in the core it should be fully compatible with webGL i guess. There's probably some stuff to do like packing resources with the binary while compiling but apart from that i think it's just a matter of compiling and removing the modules that won't work ( i guess sound and video by now )

[kalwalt]

i discovered the JopenFrameworks project and i tought that it can run in a browser. After seeing the video in the forum http://forum.openframeworks.cc/index.php/topic,6335.0.html and reading this discussion i realize that it can't as it is run in a browser. Will be nice if we can run OF application via a .js in a browser. But when it will possible? Regarding the discussion on WebGl: Does the OF team plan to add support for this project? or it something more like a parallel project. I know that Processing has Processing.js, OpeneScenGraph has osgjs.js , so i think will be super cool to have a kind of OpenFrameworks.js that can works directly in a browser.

[kylemcdonald]

@kalwalt i don't know anyone who is actively developing OF in the browser right now. the only real "plans" for OF are to keep supporting people in whatever way they're using it. but if it's something you're excited to see, we're excited to support you in making it happen :) maybe @gimlids and @arturoc can give an update on what they've found so far.

[kalwalt]

thank's for the answer @kylemcdonald ! yes i'm very excited , i'm trying right now emscrypten. I've only tested the basic examples for now. i want to see OF in my browser! In Ubuntu 12.04 64bit i installed llvm3.2 as suggested form the emscripten wiki https://github.com/kripken/emscripten/wiki/Tutorial . I'm not sure of one thing. i have installed only the 64bit version of llvm3.2 should i install also the 32 bit version? On the other hand i wan't to try also FireBreath http://www.firebreath.org/display/documentation/FireBreath+Home . i found it in the OpenSceneGraph 3 CookBook an example for integrating OSG into web browser through firebreath. When i will be familiar with the Firebreath API sure i will test it into OF.

[automata]

@kalwalt any updates? I just installed LLVM and Clang 3.2 in Ubuntu 11.10 and I'm interested in helping with oF building using emscriptem.

As pointed in https://github.com/kripken/emscripten/wiki/Building-Projects I believe we have to build every oF dependency as well...

[arturoc]

I've been looking at this recently and i also think the best option would be emscripten, nacl is another, it would be faster but it's chrome only and it requires to go through the chrome store.

emscripten supports webgl, which should work without problem with the latest programmable GL renderer, except for VAOs which i'm not sure if they work in GL ES/WebGL

and yes it needs to recompile every library we use with emscripten so a good beginning would be to start by doing that, the other thing needed would be to create the corresponding platform makefile config file.

we'll probably need to do something in the makefile to include any resource file in data in the executable although in this case the best would be to use online resources.

apart from that i think all the code we currently have should work.

[kalwalt]

@automata @arturoc for now i'm only trying to understand how emscripten works. I tried different simple examples that you can find in the tests folder and i can say that it is very easy when the code is limited to one or few .cpp or .c files. Even the ability to export directly to .html with the javascript code embedded is awesome! For me became more difficult when is involved an entire project. But as point out arturo we should recompile every library we use. The question is: should be a difference doing this in linux or windows or Mac?

the final result should be something like a of.js as for processing.js ? we should use emscripten also for testApp.* and main.cpp? or we can code directly in javascript after?

we'll probably need to do something in the makefile to include any resource file in data in the executable although in this case the best would be to use online resources.

do you mean a config.h? i looked in https://github.com/kripken/box2d.js/blob/master/Makefile and https://github.com/kripken/box2d.js/blob/master/root.h

[arturoc]

But as point out arturo we should recompile every library we use. The question is: should be a difference doing this in linux or windows or Mac?

i don't think there's a big difference, although perhaps the easiest would be on linux since most of the tools are there, being the most difficult windows since you don't even have make

the final result should be something like a of.js as for processing.js ? we should use emscripten also for testApp.* and main.cpp? or we can code directly in javascript after?

i think we should compile the apps from c++ but there could also be an option to have an of.js if that's possible. perhaps there's an option to compile the libraries only to llvm bytecode and then when you compile each app it generates the .js but not sure if that's possible

we'll probably need to do something in the makefile to include any
resource file in data in the executable although in this case the
best would be to use online resources.

do you mean a config.h? i looked in https://github.com/kripken/box2d.js/blob/master/Makefile and https://github.com/kripken/box2d.js/blob/master/root.h

there's a linker option to add resources in the final 'executable' don't remember right now what it is though

— Reply to this email directly or view it on GitHub https://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-16849560.

[kylemcdonald]

If we had an of.js that supported all the libraries we use (not just gl) wouldn't that mean of.js would be something like a 3MB download? Is it common to have js libraries that are that big?

[gabrielstuff]

this issue interested me a lot, and I can confirm you that it is not common :) 3MB is like mega huge.

Interesting talk about emscripten : http://kripken.github.io/mloc_emscripten_talk/#/14

John Resig about size : http://ejohn.org/blog/library-loading-speed/

My two cents is , what would be the purpose, does of.js will allow to develop in the browser and see in realtime what we are developing or will it just allow any of application to be ported to the browser. If it is the second then size matter and should be tiny tiny.

[arturoc]

3Mb is huge and probably an of.js would be even bigger, i think it's ok though this is not a usual web page it's a c++ app running in the browser, users won't shouldn't expect fast downloads...

also we can host the libraries with version somewhere so every app can point to the same library and take advantage of the browser cache, that way the library will be downloaded once only for all the apps using the same version

[kalwalt]

you @kylemcdonald @gabrielstuff and @arturoc are right regarding the size of the hypothetical of.js. This is a nonsense if you want make a little interactive app on the web. ( but maybe at this point better use another library, processing.js , jquery, or other) but if you want develop a 3D interactive app? see the BananBread project https://github.com/kripken/BananaBread for the code and for the demo https://developer.mozilla.org/it/demos/detail/bananabread just for an idea. The point is that Openframeworks is not a game engine but we could do very interesting stuff with a javscript version in the 3d field and with the OF flexibility.

[gabrielstuff]

if you are only interested in 3D, why not three.js ?

[kalwalt]

Absolutely yes, sure it will be easier. There are also other project like scene3d.js and osg.js (mentioned above) but i'd like to do also some little app with OF if it is possible. In these days i'm exploring different javascript libraries to find the best that fits on my ideas and Three.js is full of resources...

[ofZach]

here's a slide show about C++ and emscripten that has some useful info about porting games, etc:

http://de.slideshare.net/andreweissflog3/quovadis2013-cpp-ontheweb

[kalwalt]

thanks @ofZach the slide is very useful. it is a bit clear now some of the emscripten ascpects.

[kalwalt]

Tryed the smartest possiblity with emscripten id est run emmake make in an example folder but i got this:

emmake make Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found compiling x86_64 object for: src/main.cpp mkdir -p obj/x86_64Release/src /home/walter/emscripten/emscripten/em++ -c -Wall -fexceptions -I. -I../../../libs/glu/include -I../../../libs/FreeImage/include -I../../../libs/assimp/include -I../../../libs/assimp/include/Compiler -I../../../libs/fmodex/include -I../../../libs/freetype/include -I../../../libs/freetype/include/freetype2 -I../../../libs/freetype/include/freetype2/freetype -I../../../libs/freetype/include/freetype2/freetype/internal -I../../../libs/freetype/include/freetype2/freetype/internal/services -I../../../libs/freetype/include/freetype2/freetype/config -I../../../libs/kiss/include -I../../../libs/portaudio/include -I../../../libs/rtAudio/include -I../../../libs/tess2/include -I../../../libs/poco/include -I../../../libs/openFrameworks/ -I../../../libs/openFrameworks/app -I../../../libs/openFrameworks/graphics -I../../../libs/openFrameworks/3d -I../../../libs/openFrameworks/sound -I../../../libs/openFrameworks/math -I../../../libs/openFrameworks/types -I../../../libs/openFrameworks/communication -I../../../libs/openFrameworks/utils -I../../../libs/openFrameworks/gl -I../../../libs/openFrameworks/video -I../../../libs/openFrameworks/events -march=native -mtune=native -Os -MMD -MP -MFobj/x86_64Release/src/main.d -MTobj/x86_64Release/src/main.o -oobj/x86_64Release/src/main.o -c src/main.cpp In file included from src/main.cpp:1: In file included from ../../../libs/openFrameworks/ofMain.h:5: ../../../libs/openFrameworks/utils/ofConstants.h:143:12: fatal error: 'GL/glew.h' file not found

include <GL/glew.h>

                     ^

1 error generated. emcc: compiler frontend failed to generate LLVM bitcode, halting make: *\ [obj/x86_64Release/src/main.o] Errore 1 walter@walter-RC530-RC730:~/oF.js/of/examples/graphics/color$

shouldn't pkg's already configured with makefile?

[ddnn55]

At some point the iOS target should be specified (or better yet a more generic GLES target). That might fix some of these errors.

On Tuesday, April 30, 2013, Walter Perdan wrote:

Tryed the smartest possiblity with emscripten id est run emmake make in an example folder but i got this:

emmake make Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found compiling x86_64 object for: src/main.cpp mkdir -p obj/x86_64Release/src /home/walter/emscripten/emscripten/em++ -c -Wall -fexceptions -I. -I../../../libs/glu/include -I../../../libs/FreeImage/include -I../../../libs/assimp/include -I../../../libs/assimp/include/Compiler -I../../../libs/fmodex/include -I../../../libs/freetype/include -I../../../libs/freetype/include/freetype2 -I../../../libs/freetype/include/freetype2/freetype -I../../../libs/freetype/include/freetype2/freetype/internal -I../../../libs/freetype/include/freetype2/freetype/internal/services -I../../../libs/freetype/include/freetype2/freetype/config -I../../../libs/kiss/include -I../../../libs/portaudio/include -I../../../libs/rtAudio/include -I../../../libs/tess2/include -I../../../libs/poco/include -I../../../libs/openFrameworks/ -I../../../libs/openFrameworks/app -I../../../libs/openFrameworks/graphics -I../../../libs/openFrameworks/3d -I../../../libs/openFrameworks/sound -I../../../libs/openFrameworks/math -I../../../libs/openFrameworks/types -I../../../libs/openFrameworks/com munication -I../../../libs/openFrameworks/utils -I../../../libs/openFrameworks/gl -I../../../libs/openFrameworks/video -I../../../libs/openFrameworks/events -march=native -mtune=native -Os -MMD -MP -MFobj/x86_64Release/src/main.d -MTobj/x86_64Release/src/main.o -oobj/x86_64Release/src/main.o -c src/main.cpp In file included from src/main.cpp:1: In file included from ../../../libs/openFrameworks/ofMain.h:5: ../../../libs/openFrameworks/utils/ofConstants.h:143:12: fatal error: 'GL/glew.h' file not found

include

^ 1 error generated. emcc: compiler frontend failed to generate LLVM bitcode, halting make: *\ [obj/x86_64Release/src/main.o] Errore 1 walter@walter-RC530-RC730:~/oF.js/of/examples/graphics/color$

should pkg already configured with makefile?

— Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-17231363 .

[elliotwoods]

@walter: so gl and glew there are the only things to worry about in that list. there'll be an example somewhere on the emscripten site of how to link to gl from within an emscripten project

you'll need to hack oF a bit to have no video player / no video grabber / no cairo / etc

compiling poco for emcripten might be tougher (threads, network, filesystem all work differently in emscripten)

the other packages (gstreamer, cairo) can be dropped from the project

if you need video support later, then there'll have to be an ofHTMLVideoPlayer, or equivalent or more likely 'ofEmscriptenVideoPlayer'

my 2cents : i also think this is a lab curiosity more than a serious development ambition. i think that if you seriously want html as one of your target platforms, then you're best starting with html and encapsulating in native apps for the other targets

that said, i can see the attraction. and those slides which zach posted give a compelling case for oF to take emscripten seriously

elliot

On 1 May 2013 02:20, David Stolarsky notifications@github.com wrote:

At some point the iOS target should be specified (or better yet a more generic GLES target). That might fix some of these errors.

On Tuesday, April 30, 2013, Walter Perdan wrote:

Tryed the smartest possiblity with emscripten id est run emmake make in an example folder but i got this:

emmake make Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found Package gl was not found in the pkg-config search path. Perhaps you should add the directory containing gl.pc' to the PKG_CONFIG_PATH environment variable No package 'gl' found Package glew was not found in the pkg-config search path. Perhaps you should add the directory containingglew.pc' to the PKG_CONFIG_PATH environment variable No package 'glew' found Package glu was not found in the pkg-config search path. Perhaps you should add the directory containing glu.pc' to the PKG_CONFIG_PATH environment variable No package 'glu' found Package gstreamer-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-0.10' found Package gstreamer-video-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containing gstreamer-video-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-video-0.10' found Package gstreamer-base-0.10 was not found in the pkg-config search path. Perhaps you should add the directory containinggstreamer-base-0.10.pc' to the PKG_CONFIG_PATH environment variable No package 'gstreamer-base-0.10' found Package libudev was not found in the pkg-config search path. Perhaps you should add the directory containing libudev.pc' to the PKG_CONFIG_PATH environment variable No package 'libudev' found Package cairo was not found in the pkg-config search path. Perhaps you should add the directory containingcairo.pc' to the PKG_CONFIG_PATH environment variable No package 'cairo' found compiling x86_64 object for: src/main.cpp mkdir -p obj/x86_64Release/src /home/walter/emscripten/emscripten/em++ -c -Wall -fexceptions -I. -I../../../libs/glu/include -I../../../libs/FreeImage/include -I../../../libs/assimp/include -I../../../libs/assimp/include/Compiler -I../../../libs/fmodex/include -I../../../libs/freetype/include -I../../../libs/freetype/include/freetype2 -I../../../libs/freetype/include/freetype2/freetype -I../../../libs/freetype/include/freetype2/freetype/internal -I../../../libs/freetype/include/freetype2/freetype/internal/services -I../../../libs/freetype/include/freetype2/freetype/config -I../../../libs/kiss/include -I../../../libs/portaudio/include -I../../../libs/rtAudio/include -I../../../libs/tess2/include -I../../../libs/poco/include -I../../../libs/openFrameworks/ -I../../../libs/openFrameworks/app -I../../../libs/openFrameworks/graphics -I../../../libs/openFrameworks/3d -I../../../libs/openFrameworks/sound -I../../../libs/openFrameworks/math -I../../../libs/openFrameworks/types -I../../../libs/openFrameworks/com munication -I../../../libs/openFrameworks/utils -I../../../libs/openFrameworks/gl -I../../../libs/openFrameworks/video -I../../../libs/openFrameworks/events -march=native -mtune=native -Os -MMD -MP -MFobj/x86_64Release/src/main.d -MTobj/x86_64Release/src/main.o -oobj/x86_64Release/src/main.o -c src/main.cpp In file included from src/main.cpp:1: In file included from ../../../libs/openFrameworks/ofMain.h:5: ../../../libs/openFrameworks/utils/ofConstants.h:143:12: fatal error: 'GL/glew.h' file not found

include

^ 1 error generated. emcc: compiler frontend failed to generate LLVM bitcode, halting make: *\ [obj/x86_64Release/src/main.o] Errore 1 walter@walter-RC530-RC730:~/oF.js/of/examples/graphics/color$

should pkg already configured with makefile?

— Reply to this email directly or view it on GitHub< https://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-17231363>

.

— Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-17241164 .

Elliot Woods elliot elliot@kimchiandchips.com@KimchiAndChips.comhttp://www.kimchiandchips.com/

[kalwalt]

@elliotwoods i think that the reason for those errors is the fact that i didn't run a ./configure emconfigure before the emmake make process (because we haven't one in OF, but i'm not very expert in this field, i have a lot to learn) . the emconfigure should configure emscripten with all the packages, includes, etc as a configure always should do. Your are right about video player, video grabber and cairo. I didn't change any part of OpenFrameworks in this test. I'll have to exclude some parts of the code and to try to solve the problem of packages and especially GL. the most problematic definitely will be the poco lib.I'll have to exclude some part of the code and try to solve the problem of packages and especially GL. the most problematic definitely going to be the poco lib. yes, it is probably a laboratory curiosity, more than a serious project. I tried the three.js and is fantastic. You can create a scene with blender and export it in .json format, there is also the project threeNode.js https://github.com/idflood/ThreeNodes.js very interesting, and Sublime also has support for this library.

p.s. my name is walter but my nick is @kalwalt not @ w a l t e r . sorry for the problem!

[seacloud9]

@kalwalt @elliotwoods I have been looking into porting this library over and spent a copious amount of time this weekend trying it I am having the same issues @kalwalt was having I was just curious if anyone had made it further along? It would be wonderful to be able to use oF c++ and compile down to javascript especially now that asm.js is in Chrome Canary. http://arstechnica.com/information-technology/2013/05/native-level-performance-on-the-web-a-brief-examination-of-asm-js/

[abergmeier]

The main problems seem to be (synchronization points/threading) and messy gl. I'll have a look, but will probably have to rip apart quite a bit of code.

[arturoc]

take into account that something that rips apart quite a bit of code won't be accepted in the core :) still it'll be an interesting experiment to see what needs to be modified to get OF working with webGL.

my idea is that we'll need to ifdef or make separate implementations for non-fixed pipeline for classes like ofTexture, ofVbo and ofFbo and that poco is going to be really problematic.

are you using emscripten?

[abergmeier]

I am currently analyzing what needs to be done.

1. is replacing Poco classes behind some typdef logic, so it is possible to write a same-interface implementation for the web.
2. Replace ofThread with some kind of ofWorker. Which btw would be far superior to dealing with low level thread handling anyway.
3. See whether event notification can stay synchronous. I would prefer using notifyAsync.
4. Cleaning up GL handling.

Yes, I am using Emscripten/C++11/cmake/Eclipse. So I guess my code will not be very similar with the C++98 style you use.

[bilderbuchi]

That's no problem, our code style is detailed in https://github.com/openframeworks/openFrameworks/wiki/oF-code-style. Also, be sure to read https://github.com/openframeworks/openFrameworks/blob/master/CONTRIBUTING.md#contribute-code to see how we work with PRs etc. :-)

[arturoc]

ofWorker sounds good.

We'll also need to replace ofURLFileLoader with something that does the same but not based in poco but instead uses whatever emscripten provides to download http resources

the rest of places were we use poco is mostly for the events which is actually a bunch of headers that we could pull from poco as a first step and then utility functions that can probably just be implemented without using poco

[abergmeier]

And there is quite a bunch of code where you could replace Poco and use stdlib just fine. This will get more important over the next years, since the stdlib will get more extensive.

[arturoc]

yes that would be great, there's a group looking into making OF c++11 compatible. by now we want to only make it compile with c++11 not directly use it in the core (or at least maintain compatibility with c++98) for a while so old IDEs still are supported. but i agree removing dependencies with poco is a good idea.

[arturoc]

this is the c++11 issue: https://github.com/openframeworks/openFrameworks/issues/2577

[abergmeier]

Just to be clear: I will write in C++11. If after getting it to work, you guys want to support Emscripten, you can backport it to C++98.

[arturoc]

sounds good

[abergmeier]

openFrameworks on Chrome (via Emscripten) http://t.co/AxNopt4ZCv

[bakercp]

Exciting stuff :)

---

http://christopherbaker.net

On Fri, Jan 3, 2014 at 12:39 PM, abergmeier notifications@github.comwrote:

http://t.co/AxNopt4ZCv

— Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-31543381 .

[abergmeier]

Could someone with a compiling EGL/OGLES2 installation please make a screenshot of the customEGLWindowSettings example.

[arturoc]

yeah! have you managed to compile poco on emscripten, or did you removed all dependencies?

don't have any arm board right now with me, @bakercp @jvcleave can you send an screenshot?

[bakercp]

I am also without boards -- will have on again on Monday.

---

http://christopherbaker.net

On Fri, Jan 3, 2014 at 3:44 PM, arturo notifications@github.com wrote:

yeah! have you managed to compile poco on emscripten, or did you removed all dependencies?

don't have any arm board right now with me, @bakercphttps://github.com/bakercp @jvcleave https://github.com/jvcleave can you send an screenshot?

— Reply to this email directly or view it on GitHubhttps://github.com/openframeworks/openFrameworks/issues/1319#issuecomment-31556226 .

[kalwalt]

hi, @abergmeier did you manage to compile OF with emscripten? if yes you are great!

[abergmeier]

@arturoc yes, I compiled Poco and all dependencies. I use some experimental extensions to Emscripten we are working on.

@kalwalt Let us wait till you saw all the modifications to the source I had to do ;)

I am doing this as my Bachelor Thesis, so will post both the repo and full writeup what I did when I am done. In the end we will have to dispose of sndfile, since its' License does not allow for linking in.

BTW: Is someone working on exception safety/consistency in the code?

[jvcleave]

screenie

[abergmeier]

Thanks @jvcleave So I guess since the z rotation seems right, that the problems lies either within the matrix math or the texture coords. Is anyone familiar with the TARGET_OGLES code in IRC these next days?