ice1000 / jimgui

:sparkling_heart: Pure Java binding for dear-imgui
Apache License 2.0
185 stars 13 forks source link

Improve item and texture bindings #43

Open thecodewarrior opened 5 years ago

thecodewarrior commented 5 years ago

I'm working on porting an app from the (frankly shoddy) Kotlin ImGui port, and while overall the change has been a positive one (if painful), I've run into a couple issues with binding support.

The first thing I noticed not being bound was the JImGui.listBox function, along with the itemSize and itemAdd functions. The listBox was trivial to reimplement, and I figured out that the JImGui.rect method creates an item, so I'm using that temporarily.

I'm also using a lot of custom BufferedImage textures (I'm using it to render reference glyphs to an image to draw in imgui), but the texture support in jimgui doesn't quite support this. Firstly, in order to export a BufferedImage to ImGui I would have to write it to a byte array as a .png for ImGui to read, which seems far from ideal. Secondly, I update these textures relatively frequently, so the fact that there isn't a method to replace or release a texture after it's created means old textures would just end up piling up.

This isn't really hampering development much however, since at the moment I've got workarounds for the missing JImGui bindings and I'm not working on the section that uses the textures at the moment.

ice1000 commented 5 years ago

The signature of listBox is ListBox(const char* label, int* current_item, bool (*items_getter)(void* data, int idx, const char** out_text), void* data, int items_count, int height_in_items = -1); or ListBox(const char* label, int* current_item, const char* const items[], int items_count, int height_in_items = -1);, which includes either a string array or a callback function. I haven't decide on how can I design such JVM API yet, because passing a Java array to C++ through JNI is expensive (so does converting string and pass it through C++).

ice1000 commented 5 years ago

I'm also using a lot of custom BufferedImage textures (I'm using it to render reference glyphs to an image to draw in imgui), but the texture support in jimgui doesn't quite support this.

Yes, because imgui accepts textures supported natively by the GL backend you're using. If I want to support BufferedImage, I can't do more than just converting your BufferedImage into byte[] and pass it into existing APIs.

ice1000 commented 5 years ago

Most of your questions are related to the design of the original imgui implementation. I'll recommend you to take a look at some FAQs provided by https://github.com/ocornut/imgui and see how things are going.

Like, loading image needs to be completely implemented by yourself (using DirectX API or OpenGL API, for example). I'm already doing this for you -- on Linux/macOS it's: https://github.com/ice1000/jimgui/blob/a0b56fd8ea52f6801b70f13a201d9c05a34d0571/core/jni/glfw_impl.cpp#L73-L124 https://github.com/ice1000/jimgui/blob/a0b56fd8ea52f6801b70f13a201d9c05a34d0571/core/jni/glfw_impl.cpp#L45-L58

For Windows it's: https://github.com/ice1000/jimgui/blob/a0b56fd8ea52f6801b70f13a201d9c05a34d0571/core/jni/dx9_impl.cpp#L49-L108

I assume you're not asking for JImTexture(long nativePointer) -- which might be useful for you.

ice1000 commented 5 years ago

So the problem is jimgui uses DirectX (9, if you're asking for the version. But 11 is planned) on Windows, while the reimplementation from kotlin-graphics is completely based on some OpenGL thing (thus rendering details can be customized as well).

ice1000 commented 5 years ago

For the listBox thing, if you have an idea in mind, don't hesitate to tell me (or pull me).

ice1000 commented 5 years ago

I update these textures relatively frequently, so the fact that there isn't a method to replace or release a texture after it's created means old textures would just end up piling up

This sounds like you're asking for an API to release textures. Contribution is also welcomed.

ice1000 commented 5 years ago

/cc #11