Replies: 3 comments 16 replies
-
|
Hi @lopcode, sure, I'll add a note, it looks nice. It seems to be generating off the C++ headers, is that right? I suppose (in my mind) the ideal JVM binding would target the lower-level libvips GObject API, rather as the C# binding does. It would make the whole libvips API available, wouldn't need the (often rather fragile) header parsing, and would automatically update itself for whatever libvips binary it detected at runtime, rather than being tied to a specific libvips version. I'm sure you saw https://www.libvips.org/API/current/binding.html However! That's quite a bit more work, and I can see that pragmatically your approach is easier. Thanks for letting us know! |
Beta Was this translation helpful? Give feedback.
-
|
Here's the bit of netvips that calls a libvips operation: https://github.com/kleisauke/net-vips/blob/master/src/NetVips/Operation.cs#L138-L254 That uses libvips introspection to call any operation in the libvips binary, passing and converting arguments back and forth. There's similar code in the C++, python, ruby, php, lua, etc. bindings. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for looking, appreciate you adding a note, and for the pointer to the C# bindings. The main benefit of targeting the GObject API seems to be "automatic" updating for API changes which does sound appealing. I did see the bindings section on the website and went for something closer to the "Dynamic language with FFI" option, except I'll play around with it, thanks again 👍 |
Beta Was this translation helpful? Give feedback.
-
|
They're turned directly from GTKDoc to Javadoc with some regular expressions - most of it is fine, but there were some fixups needed at the end (especially relating to tables tables) needed to make them valid: https://github.com/lopcode/vips-ffm/blob/main/generator/src/main/kotlin/vipsffm/GenerateVClasses.kt#L290 |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I mean formatted HTML docs I could read somewhere. I was just wondering what they look like, how links work, that kind of thing. Other bindings have a copy of the formatted docs in github pages, for example: |
Beta Was this translation helpful? Give feedback.
-
|
Ah I misunderstood! There's no website or rendered HTML docs at the moment - something I need to get around to 🙂 |
Beta Was this translation helpful? Give feedback.
-
|
This was easier than I was expecting with Javadoc, especially now it supports Markdown so I can use the GitHub README as the "website overview". The VImage docs for example: https://vipsffm.photofox.app/app.photofox.vipsffm/app/photofox/vipsffm/VImage.html |
Beta Was this translation helpful? Give feedback.
-
|
The GIR docs drop in well! It's very close! It's a shame gtk-doc markdown doesn't support tables directly. The in-line HTML tables end up as text :( I'm sure you don't need more suggestions, but just in case ... the C++ binding has a set of extra hand-written convenience methods, perhaps you saw: https://github.com/libvips/libvips/blob/master/cplusplus/include/vips/VImage8.h#L1119 Adding something like that would you write code like: c = a.less(12).ifthenelse(14, b);Which would find pixels in |
Beta Was this translation helpful? Give feedback.
-
|
I've promoted the most recent build to Also discovered that JVips is quite out of date at the moment (2 years at least) - I had planned to benchmark against a recent release, but it seems there's binary compatibility issues between it and recent libvips releases. |
Beta Was this translation helpful? Give feedback.
-
|
Great! You must be pleased. I hadn't realised jvips was languishing :( that's a shame. |
Beta Was this translation helpful? Give feedback.
-
Hi there,
Thanks for working on libvips!
This is just a heads up that I shipped Java/JVM libvips bindings that use Java's new FFM API (Foreign Function & Memory API) from JEP 454. The bindings are automatically generated from headers (via a new JDK tool called jextract), and then again automatically processed with some custom code. The second pass makes a "helper API" that is safer to use than the "raw" C stuff (as noted on your website), and more idiomatic for JVM systems. In theory there should be ~100% API coverage, assuming Java's generation tooling picked everything up, and updating for new libvips releases should be easy.
No doubt there are additional improvements to make, but I think things are good enough to use now. The project's over here if you'd like to take a look: https://github.com/lopcode/vips-ffm
I was wondering if you would consider signposting it on the libvips website? No problem if not, and I know there are other more mature JNI-based solutions available too. But I thought the new project might be useful for others, so wanted to reach out and ask.
Thanks again,
lopcode
Beta Was this translation helpful? Give feedback.
All reactions