strukturag
Add heif_items API to emscripten
I would like add the heif_items.h API so JavaScript application can leverage that functionality.
I'm still trying to compile libheif to JavaScript/WASM so I can't test out the code yet, but I wanted some initial feedback on this task.
Main hurdle might be that we do not do any encoding and writing of HEIFs in JS yet. You cannot add items to existing files (yet), even in the C API.
Half the emscripten functions have the js prefix and the other half don't.
e.g.
heif_context_read_from_memory()
heif_js_check_filetype()
It would be nice if there was a more consistent naming convention, but this might be a breaking change. Any thoughts?
Half the emscripten functions have the js prefix and the other half don't. e.g.
heif_context_read_from_memory()heif_js_check_filetype()
Yes. I think originally every function that required an explicit JS wrapper got the _js_ prefix. But I guess that this is not necessary. We can simply put the original name into the function table and reference the _js_ function from there. We could also leave the old _js_ functions in the table to avoid breaking backwards compatibility (and add a deprecation comment).
The convention could be: use the original name when the function is the equivalent of the original function, even if they required a wrapper. Functions that are JavaScript specific (e.g. heif_js_decode_image2) keep the _js_ prefix.
For heif_item_get_item_type() vs heif_js_item_get_item_type_string() it's a bit tricky. I would argue that working with uint32_t on the JS side is inconvenient such that we always use strings for four-cc codes. Hence, the original name heif_item_get_item_type() is ok despite the changed type.
The PR now:
- Adds the heif_item.h API
- Adheres to a naming convention & deprecates functions don't follow it
- Ignores the buildjs directory
- Uses alloca() instead of malloc()