On my Raspberry Pi Zero a Node-red function can comfortably read a counter from context, increment & save it and pass the result on more than 1000 times a second.
So a flash of the wire as it passed would be imperceptible.
I can envisage the wires's glow decaying over perhaps .025 sec which maybe could be done via CSS and some extra code in wherever a message is propagated from one node to the next.
It would have to depend on a special setting though - myEditorISADashboard = true maybe
The same setting could cause the currently active node to glow too?
And yeah - asking the browser to update something 1000 times a second is really not good for performance - replicated across many wires/nodes etc... That is why the status indicator is meant to show things like the state of a server connection or the odd error condition and not be a dashboard.
I do recall a thread some time ago about "auto clear" of the status indicator. One of the things that initially tripped me up was seeing the last status - that may have been from days ago. Perhaps something as simple as decaying status would go someway to providing clearer status?
Well if that status (from several days ago) is still the status then wouldn't you want to know ? (if a node isn't clearing it correctly then yeah - it needs to be fixed)
(And yes there is a wider topic of better inline debug) - maybe via an inline node - or variation to the debug node - or hover over something.... or... )
What are the performance / memory consequences of updating a debug node status 1000 times a second? (ie under the node, not output to the debug pane)
It does seem to be able to keep up with an inject every millisecond, though of course there may be an increasing lag or memory use.
I know a CSS transition over a quarter of a second must surely lag.
Nope, not a serious suggestion, just wondering how much of a problem it would be.
The debug node has special code in it to buffer up messages - If there are more than the scrollable display window depth they get dropped - so only the last visible ones end up getting sent - but even so it can lag quite a bit if pushed.
Some other nodes (like delay node I think) also rate limit status updates to something like 2-3 per sec).
There is no need to have lines, borders and messages be on always (as in a plc editor) one just turns on watch (or simulation) mode. Node could most likely handle this with ease, since it only requires to update the currently visal nodes with lines.
if it already can handle the 1000's or 100000's of messages without delay on even a raspberry pi why would this even be a problem since it clearly does not require to update the entire project?
Anyway i don't see why this would not be a good thing.
As i'm not into developing node-red itself maybe someone could look at if this is possible to add to the debugger (plugin) for testing?
thanks for your interest.
I've searched alot, but could not find any information about such feature request (the current topic looks most like it).
Sorry i don't see why a computer (node) could not handle such simple visual representation with ease. Ofcourse there may be some performance impact, but again it's not meant for production (dashboard) only in the editor to visualise the flow of messages to the developer.
I don't know the underlaying api's but i see each node can sent a status already, so lighting up the line looks to me do-able.
I think it should be added to the node-red-debugger and maybe under a "watch" mode that can be enabled.
Knowing this community a bit, we all would appreciate if you created a PoC that underlines your assumptions. That could be a great starting point then to include this feature into node-red-debugger.
