Remote ImGui for Arduino

[G-glop]

Hello, after following the ImDuino project, i decided to try make remote ImGui for Arduino.

I could do the same as Remote ImGui and simply send the generated verticies, but such approach is so heavy compared what could be done instead.

What I plan to do, is to "simply" remove all vertex processing from the remote. I know it's a pretty big undertaking, but the benefits would be large:

• Less bandwidth
• Less CPU, by not compressing and by not generating any verticies in the first place
• Less memory, by streaming the data as is it's generated
• Almost no dynamic allocations, only for stuff like TextEdit (maybe some more to get rid of the snprintf buffer in ImGuiContext)

Currently i'm marking up all the places that need to be cut out, but i don't know ImGui inside out, so there are some places that i need clarification on. (eg. ShadeVertsLinearColorGradientKeepAlpha is used inside ColorPicker by capturing before and after vert write pointers to color the result of a path, so maybe make it a part of the path API?)

I don't think much functionality will have to be dropped, obviously render callbacks are a bust, and i'm not sure about images, but other than that everything else should be preserved. (fonts in particular can be optimized down to the x advance per glyph)

On a similar note: to get over the whole versioning thing, the client could be compiled to WebAsssembly and served from the microcontroller, so the two pieces could never get out of sync.

[ocornut]

Hello @G-glop,

This is an interesting topic and I imagine eventually I would want to go into this direction to make something like this (and https://github.com/JordiRos/remoteimgui) an optimal, first class citizen within the imgui ecosystem.

90% of it boils down to reimplementing ImDrawList, we could imagine an imconfig.h define to disable ImDrawList declaration/implementation completely so the user could provide their own. ImDrawList is currently about 700 lines so it's not that much work.

At the moment you can ignore the ShadeVertXXX functions, but basically you would only need to push the equivalent command+data in your own command stream and then you can apply the similar effect on the viewer side. The immediate issue is that they are currently implemented as internal ImGui:: functions and not inside of ImDrawList, but if we use that define to disable ImDrawList we could 1) also disable them to let you reimplement them, and possibly move them to ImDrawList, 2/ change their signature so they are easier to replace in a vertex-less implementation (e.g the signature could change from ImDrawVert* vert_start, ImDrawVert* vert_end to ImDrawList, int vert_start_idx, int vert_end_idx.

The same technique could be used at the Arduino scale but also for high-end network transport and we could imagine a protocol for sending textures, etc.

An older project which had to do something similar:
https://github.com/jonvaldes/tear_imgui

(Linking to #75.)