Supporting websocket

[THISISAGOODNAME]

Hello,

I managed to make NetImguiServerApp running on html , but on html5 you can only use websocket API. It would be fine if netImgui client will support websocket.

Thank you!

[sammyfreg]

That's nice!

I have zero experience in web dev (beyond html years ago).

However, this could be accomplished fairly easily I believe when having web experience. The codebase has been designed to support easy integration of other socket support. All it needs is a new file with websocket support, duplicating the content of NetImgui_NetworkPosix.cpp or NetImgui_NetworkPosix.cpp. They basically need to implement 4 functions Connect, ListenConnect, ListenStart, Disconnect which are thin wrapper around platform specific socket.

[ozlb]

Probably you can get inspiration from this project: imgui-ws

[THISISAGOODNAME]

https://github.com/sammyfreg/netImgui/assets/5005612/a3a87e36-82c1-4736-9cad-ad2263d4c17e

It finally works, thanks a lot.

[sammyfreg]

That's nice! Pushing the code you had to do to support this? Might interest a few people. Though, how much changes was needed to have the Server application run in html5.

[THISISAGOODNAME]

https://github.com/CU-Production/NetImguiSokol/tree/wasm

I don't know how to use sharpmake with emscripten, I use cmake as build system.

[sammyfreg]

Out of curiosity, was there a particular reason you chose to port NetImgui to Html5? I believe there's already 2 other solutions for web usage of Dear Imgui (like imgui-ws ). I have not used the other projects, so I was wondering if there was some additional benefits to using NetImgui.

[THISISAGOODNAME]

1. NetImgui client API is easy to intergrate, and no other third-party dependencies
2. NetImgui server app UI is easy to use

[sammyfreg]

It looks like you managed to use the standard socket code, without needing anything websocket code? I might look at your sokol/emscript (more difficult) to import them later.

[THISISAGOODNAME]

It looks like you managed to use the standard socket code, without needing anything websocket code? I might look at your sokol/emscript (more difficult) to import them later.

https://emscripten.org/docs/porting/networking.html#full-posix-sockets-over-websocket-proxy-server

I use websocket_to_posix_proxy as a proxy server, and I can do zero modification for NetImgui Client.

[hinxx]

I apologize for butting in like this in this discussion. I was trying out netImgui and imgui-ws to see how they behave. For imgui-ws I'm observing a 100% CPU load on the web browser all the time (one core only; seems single threaded on browser side). At this point the user interaction is OK. I need to use implot, too, so when I get 1 or 2 plots up the user experiences a lot of lag on the web browser side. With >2 plots it becomes unusable.

@THISISAGOODNAME do you have any performance metrics on your approach with websockets behaves?

I'll need to double check what I observed with the netImgui, but IIRC, if there is a lot of vertexes to be drawn I basically resulted in heavy network traffic (which in my case is not an issue on the 1Gb LAN I'm working with).

[sammyfreg]

I just noticed this comment. I haven't tried this web server port, but wanted to let you know that NetImgui Server supports compression for the Draw Commands to drastically reduce network traffic. As for the 100% CPU usage of imgui-ws, the NetImgui Server avoids this by using a 'sleep' instruction in each thread to release the CPU at the end of each loop , but I am not sure how this is panning out for the web version.

[hinxx]

I think that compression for the Draw Commands does not help much in my case when I want to plot 10k points in the implot widget. The points are digitized data from the "real" world hence having high cardinality (imagine plotting a trace with a noise component).

[sammyfreg]

You are correct, the compression wouldn't be great. I implemented a simple scheme that only transmit the vertex difference from last frame. So in your case, with highly mobile plot data, it wouldn't compress well. What I could suggest, is to keep the refresh rate as it is but update the plot locations at a lower FPS (say 1/2 or 1/3) to keep the UI responsive, but greatly reduce plot traffic.