On 1/13/17, Eric Wing <ewmail...@gmail.com> wrote:
> On 1/13/17, John Spikowski <supp...@scriptbasic.org> wrote:
>> I think any major directional changes should include a web IUP as a
>> consideration. IMHO
>
> I think this is a really interesting idea and I would love to include
> this. I've done a tiny bit with Emscripten/asm.js, but I am no means
> an expert. I am also not a web person so I don't have the domain
> specific knowledge on what a backend should look like.
>
> At a very high level, I think it should work like the following:
>
> (1) You should be able to take your C based IUP application, and
> compile it through Emscripten. Emscripten/IUP should have some kind of
> implementation for all the library calls (I'm guessing implemented in
> JavaScript for the web browser, though maybe it is CSS/HTML?). The
> final output Emscripten generates is a web site (with all the C
> converted to JavaScript), which is your original program now working
> in the web browser.
>
> (2) Emscripten/IUP should be able to output just a JavaScript/web
> module that web application developers can import into their projects.
> They can write new IUP applications completely in JavaScript for the
> web browser and will not have to write any C.
>
>
> (3 bonus) Presumably, other people may want native JavaScript bindings
> (aka non-web, directly to JavaScriptCore, v8, SpiderMonkey, DukTape,
> etc.) to IUP. (If you are confused by this concept, see my JavaScript
> talk from the Lua Workshop 2016
> https://www.youtube.com/watch?v=Xi_eMGO3g-o)
>
> The Emscripten/IUP JavaScript web API should be the same as any direct
> native JavaScript bindings to IUP/C. That way a developer who writes
> an app completely in JavaScript, can easily transplant it between the
> web browser and a native IUP app using the JavaScript bindings.
>
>
> In terms of IUP changes, I don't see it much different than what I'm
> doing now. I do know the existing IUP event loop will be a problem,
> however, I believe my event proposal should fix this one too. Since
> the web works on both desktop and mobile too, I suspect it will just
> be able to leverage what's already there.
>
> But as I said, I currently don't have the expertise in web backends or
> Emscipten to say more than this. So if we can find somebody to step up
> as the expert for this, then that would be great.
>
> Thanks,
> Eric
>
John,
This is an excerpt from SDL 2’s CreateWindow backend for Emscripten.
static int
Emscripten_CreateWindow(_THIS, SDL_Window * window)
{
SDL_WindowData *wdata;
double scaled_w, scaled_h;
double css_w, css_h;
/* Allocate window internal data */
wdata = (SDL_WindowData *) SDL_calloc(1, sizeof(SDL_WindowData));
if (wdata == NULL) {
return SDL_OutOfMemory();
}
if (window->flags & SDL_WINDOW_ALLOW_HIGHDPI) {
wdata->pixel_ratio = emscripten_get_device_pixel_ratio();
} else {
wdata->pixel_ratio = 1.0f;
}
scaled_w = SDL_floor(window->w * wdata->pixel_ratio);
scaled_h = SDL_floor(window->h * wdata->pixel_ratio);
emscripten_set_canvas_size(scaled_w, scaled_h);
emscripten_get_element_css_size(NULL, &css_w, &css_h);
…
So, the major thing to note is the emscripten_ prefixed functions.
Emscripten does provide an API for C to do basic web browser things.
https://kripken.github.io/emscripten-site/docs/api_reference/emscripten.h.html
I do not know if there are enough API functions exposed to implement
complete coverage for IUP's APIs. Emscripten was driven mostly for
porting games which doesn't need a lot from browser UI. For example, I
couldn’t find anything named ‘button’. But I’m not a web dev, so maybe
its called something else. If there is enough to provide full
coverage, then implementing an Enscripten/IUP backend should be pretty
straight forward. It will just writing in C and filling in the right C
APIs to call.
If there is not enough, it looks like there are two approaches to fill
in the holes:
https://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html#interacting-with-code-call-javascript-from-native
1) Execute JavaScript from C
Example:
emscripten_run_script("alert('hi')");
Though, they seem to recommend this macro syntax as faster/better:
EM_ASM(
alert('hello world!');
throw 'all done';
);
2) Implement your own C API functions for Emscripten in JavaScript
// In C
extern void my_js(void);
int main() {
my_js();
return 1;
}
// In JavaScript
my_js: function() {
alert('hi');
},
=========
So the final piece of the puzzle is function pointers and crossing
back from JavaScript into C.
So as an example, if we create a JavaScript button, presumably, there
is a JavaScript callback function event. We want to be able to invoke
a C function from this callback.
So to make a C function callable by JavaScript:
// In C
int int_sqrt(int x) {
return sqrt(x);
}
// In JavaScript
int_sqrt = Module.cwrap('int_sqrt', 'number', ['number'])
There may be a build system requirement that you must list exported functions:
./emcc tests/hello_function.cpp -o function.html -s
EXPORTED_FUNCTIONS="['_int_sqrt']"
I’m not sure if we will need any more functionality for function
pointers, but the documentation has one more short section mentioning
Runtime.addFunction
Unfortunately, I’m finding the explanation a little sparse.
There are additional caveats, like things JavaScript developers
shouldn’t do in Emscripten, and special memory related things to get
more performance out of the code.
But overall, assuming the above is all we need, it actually doesn’t
look that bad. (It looks easier than Android in most respects.)
Somebody who is really interested in seeing this backend happen,
should contact the Emscripten people. I think there is a chance they
could be intrigued by this project and may be able to offer
guidance/help in some areas.
Also, just thinking out loud, but I think this could make a really
good Google Summer of Code project. It looks like organization
submissions start Jan. 19th.
https://developers.google.com/open-source/gsoc/
(Maybe the Mac, iOS, and Android backends would make good GSOC projects too.)
As a community, maybe we should try to organize a mentorship for this summer.
-Eric
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
