Feature request: Accessor API in ThorVG.WebCanvas

[huming2207]

Hi all,

We need an API for traversing a rendered object tree and find the relevant object by given string ID. It's achievable by using ThorVG's Accessor API if that's in native C++. But it doesn't exist in this WebAssembly library.

I think I can make something by exposing the tvg_accessor_xxxxx() APIs by setting the EXPORTED_FUNCTIONS and call the exposed C APIs in the JS side.

But then I think it's not that trivial. Firstly I'm not sure how to handle function pointers in those exposed C API (i.e. how do I make a C callback and point it into tvg_accessor_set()? I'm not sure). Second is I don't know how to match the JS API

Maybe another way is to expose the ThorVG Paint object's hash ID to JS (i.e. make a tvg_paint_get_id() C API that returns the uint32 hash ID) and then port the hash algorithm to JS, then we do a match in JS, which is probably both more efficient and easier to implement.

I will continue working on this later this week and see what I can get it done. I may submit a PR afterwards if I make some progress on this. Please also provide some suggestions if you have any better suggestion. Thanks in advance.

Regards,
Jackson

[tinyjin]

@huming2207 Thanks, feel free to raise PR, or reqeust. We'll review then!

[huming2207]

But then I think it's not that trivial. Firstly I'm not sure how to handle function pointers in those exposed C API (i.e. how do I make a C callback and point it into tvg_accessor_set()? I'm not sure). Second is I don't know how to match the JS API

Sorry I was rushing back home earlier, didn't finish this sentence.

I mean I am not sure how to match the JavaScript side Paint object with the ThorVG/WASM side's Paint object. I guess the best way is probably to make a lookup table to match, but that's inefficient as well.

Therefore I think the most trivial way is to implement a tvg_paint_get_id() in ThorVG, expose this function symbol and port the hash ID generation to JavaScript side, then match this hash ID. But then I need to make two PRs, one for ThorVG library itself and one for this ThorVG WebCanvas WASM wrapper. However I still think I'd take this approach as it's probably the most efficient option. It will become a simple "hashmap lookup" with the least WASM/JS interops.

What do you think? Any better idea? @tinyjin @hermet

[tinyjin]

@huming2207 Ah, I was thinking that you want to be going to make a PR.

Haven't fully reviewed, but I don't think it's worth building internal hash map in JS side. We can simply wrap the tvg_picture_get_paint, and introduce paint.id(tvg_paint_get_id, getter) in Paint object.

JS map causes not only efficient problem but the synchronization issue also. Accessor API is used for Lottie/SVG based on their layer name. We won't need ID generation(maybe you just meant hashing), so yes JS can do the DJB2 hasing and can be used.

--

This week, I might not be capable reviewing this. You can freely start contributing if you want. Otherwise, leave to me.

[huming2207]

Just added tvg_paint_get_id() function in C-API. See thorvg/thorvg#4184 @tinyjin

I will work on the JS wrapper tomorrow.

[huming2207]

Hi again @tinyjin @hermet

So far I've done the ID getters but I'm still not sure how to match the JS side's Paint wrapper object to the WASM-side's Paint object. Even if we have a tvg_picture_get_paint(), how can I match the WASM Paint object with the JS Paint wrapper object? I think we still need a traversal thing that able to traverse the JS object's tree first. I will probably leave the rest of the part to you for now.

Meanwhile we will probably also need to move on implementing some extra customised addons to the ThorVG C/C++ side, as we under estimated what we actually need yesterday. It's much more complex than just a simple traversal, ID matching and change the text in a element, therefore we need to do it in C/C++ and expose one single API to reduce interops. Those customised stuff will not be upstreamed at this stage as we might breach the NDA. But yes we will finish off these two PR for adding the ID getter and setter as we also need this part anyway.

Regards,
Jackson