@Steve-Mcl and I developed last year the node-red-contrib-ui-svg node, but seems we have a performance problem for larger drawings. I managed to solve one of the causes, but now I'm stuck with the large number of TypedInput fields that are being used:
Appears this is a known problem in Node-RED, but the core nodes workaround it (in a way that we cannot do).
When I use the profiler of my Chrome developer tools, I see lots of resizing calculations for all the TypedInput's:
Which is being triggered for every TypedInput that we add, via addItem:
Since we call the addItem lots of times for large drawings, this will cause a lot of resizing.
Think it would be solved if the resizing was only done once at the end, but I assume that isn't possible.
But this is becoming a bit too complex for me
Is there anybody who has an idea how we can solve/workaround this?
A couple of ideas Bart (but they don't fix the typedinput issue you're seeing)...
Replace the individual elements with a table and an edit button column that enables the row for editing and then shows a newly created typedinput. (So only one in memory/on screen at a time)
A more simple list with edit button that pops up an edit dialog.
Neither are ideal but should work.
Tbh, I'm seeing lots of nodes with this type of list - it would be fantastic if a grid like editor was built in (like configTable or something)(is there something like this already?). Ps, I'm not asking any Dev to dive on this - just that I'm seeing a pattern and tbh, setting up these lists are a bit of a pain. Alignment issues, sizing issues blah blah.
That are indeed possible workarounds. My gut feeling says that it would be very difficult to solve the root cause in the core of Node-RED, so I might have to go that way ...
In this particular case, the caller can also workaround it by adding less items to the table (by using CSS selectors). But in the near future, there will be drawings that run into problems anyway. So we should solve it one way or another.
Well of course you don’t have to. But you have a performance problem so it’s your trade-off. I think Nick is aware of the issue but somewhat busy (as ever)
FWIW, I've spent an hour today changing the TypedInput to use flexbox css which means I have been able to remove all of the expensive code we had for resizing - it is all now handled by the browser's native CSS handling which is a much better place for it to be. Have tested across Chrome, FF, Safari and even IE11 and it all looks good.
Hi Nick (@knolleary),
Just confirming that indeed version 1.0.5 fixes this problem very well!
While the previous version of this particular SVG node's config screen (of a large SVG with lots of typed inputs) took more than 15 seconds to load, now it only takes maximum 3 seconds.
So nice job again! Thanks !!
) some major refactoring.