-
Notifications
You must be signed in to change notification settings - Fork 27
Too slow editing/saving node with huge SVG #50
Comments
Just noticed ver2.0 description, I have to try it |
Hi Andrey, The 2.0.0 version is not released yet on NPM due to the lack of time.
A question about your SVG:
Could you explain where your png image is located, and how you expose it to the dashboard this way? Was looking myself for a secure way to use private images inside my svg... Bart |
P.S. The 2.0 version contains a breaking change unfortunately. Please have a look at the start of the readme page for more information. |
Hi Andrey, |
Morning @andreypopov, Sorry for keep you waiting! But before I merge your pull request, I would first like to try whether we can make it faster. Just to be able to keep the same functionality for large SVG's. If that fails I will have no other choice then using your checkboxes... P.S. would you be so kind to respond to another issue please. Perhaps you can explain there how you use your local image path. Think you might help lot of users with that. Thanks !! AutocompleteCould you explain shortly how you have measured that the autocomplete was one of the bottlenecks? I have added a fix for the autocomplete on the "panzoom" branch. Now the autocomplete is only added once the user clicks on an element, instead of adding autocomplete to all elements at conf screen startup:
I have done this for all autocomplete fields, so hopefully that helps. Would be nice if you could install that branch and do your performance test, and let me know if I should keep this fix. TypedInput'sWhen I use the profiler of my Chrome developer tools, it seems there are an awful lot of resizing calculations for the TypedInput's: Which is being triggered as soon as we do an I think it would be better if the resizing was executed once at the end... But I have no clue at all whether that is possible. Did you have the same conclusion, or did you see something else going wrong perhaps? Seems this is a known problem , but they haven't solved the root cause since they have added workarounds to their nodes (change node...). Don't think these workarounds could be introduced here, because they only apply now TypedInputs to visible fields. But all our TypedInput fields are already visible in our table ... I will discuss this on the forum as soon as I have time. So please share me your analysis of the problem, so we can explain correctly to the folks what is going wrong... Thanks !!! Bart |
That was my suggestion, I disabled it and found performance boost. I don't know how to accurate measure it.
Yes, the same conclusion. It is typedInput's issue. Can we init it onclick like autocompletes? btw. node's saving is also so slooow.. my svg node is still growing :) |
Hey Andrey, Sorry but I'm really short of free time lately. I have now created a discussion on the Node-RED forum, and hopefully I get the golden tip to solve this. P.S. There is another workaround, since you can replace a series of event handlers by a single one, when you should use CSS selectors. See an example on our wiki page. Then your config page becomes more simple and readable. Will keep you updated if I should get an answer from anybody. Bart |
Good news, |
Evening Andrey (@andreypopov), But there is still a problem with the layouts of the typedinputs. I have reported this problem and Nick has solved it already in Node-RED 1.0.6 (which will most probably released next week). P.S. I did test this on the "panzoom" branch, which contains also my fix to lazy initialize the autocomplete fields. |
Hi @andreypopov, |
Hi @andreypopov, |
I assume it is solved ... |
my svg node is 100kb+
try to import, edit and save. We need some optimization here..
I use the latest macbook pro 2019/ 64gb ram
The text was updated successfully, but these errors were encountered: