ElemeantaFrameRate.vl (41.9 KB)
Patch demos the issue, I have a dynamic Gui, this parts demos the main slow down, values need to be set into the widgets reflecting changes upstream and it can set them downstream in the datatype.
Elements can get added and removed also. I get 20-30 ish fps with just this patch.
What can improved, or is it an issue?
Hmm ok, and if I need to delete them or reorder? (could be any, as I said they are dynamic, should I deal with them as particles, ie spawn update and delete them that way?). I think I need to find a tutorial on classes, I appreaciate they work, but whenever I have worked on a patch with them, I find it hard to debug as the workings can seem a bit hidden. I’ll try and get the drop down working…
Thanks
ElementaFrameRate_Cat.vl (64.3 KB)
Didn’t take me long to break it :D
I’ve tried setting the dropdowns on create, so they start with a value (otherwise they were blank) the list can change so I’ve put that in an setvalue. But I can only change the value in the set operation, and it doesnt work in the gui, except the one in the set. Also restarting the patch, and I get a scenewindow error
Put them inside a Cache region or an AsyncTask to do the creation in background. I had to do both (see patch) otherwise recreating them causes a memory leak. Not quite sure what is happing there and no time to investigate. Probably a mem leak also caused your crash.
The dropdown seems to be a special case, it has an Update operation that needs to be called so it works properly. Didn’t check other widgets.
Instead of outputting the wrappers separately like you did now they could all implement the same interface (“IWidgetWrapper”) and be joined in one spread just like the widgets (which implement IElementum). To address the different types later on you can then use OfType.
ElementaFrameRate_b.vl (72.0 KB)
That looks great, thank for your help!
I can’t work out how to make IWidgetWrapper work, the outputs are currently an IElementum and a StateOutput, and I can’t work out where that even comes from in the class as none of the outputs are that type. I see that it has a process node called that, but where is that happening in the patch, it doesnt seem to be defined?
Is there not a way of getting and setting values using an IElementum, eveything widgety is surely inside that link?
I though the way to do it was make the interface with a StateOutput and IElementum, but really I am lost.
ElementaFrameRate_c.vl (74.8 KB)
The culprit in your original patch seems to be the Flatten node. It causes a new spread to be created every frame which in turn causes the Elementa widget graph to get re-calculated. The moving circle on the tooltip can help a lot in such cases. If the circle is filled (flashes up) it means that the data is constantly changing. In case of widgets graphs like Elementa that’s most certainly a bad sign.
In your case the solution is rather straight forward, put another Group node inside the loop, so you end up with a Spread<IElementum> instead of Spread<Spread<IElementum>>. You can then also get rid of the background thread hack.
ElemeantaFrameRate_NoFlatten.vl (38.2 KB)
Ah, ok, that seems to give around the same performance as wrapping it in a class. Thanks for the clock tip as well, I’ll go through and try and find any other instances of my doing that!
Hello Elias, I developed a large GUI using your example (ElementaFrameRate_NoFlatten) witch combines static and dynamic widgets in different panels, and I also use tabs. But I’m still facing a drop of frame rate that is definitely linked to the amount of widgets in my patch.
Does panels have an impact on frame rate too ? (I removed all the stacks from my patches).
Any other advice on how I could fix this issue? i can provide a patch if needed.
Many thanks for your reply
A patch will help indeed!
Here we are. Here is a simpler patch that I created for audio analysis purpose. It’s for tests purposes as it’s originally part of a bigger patch. Also it’s my first project created coming from beta so I may have bad practices. It’s not the one with tabs but architecture is similar.
Gui-FrameRate-Test.vl (509.4 KB)
Many thanks again for your time and reply
happy new year
While it would certainly help to cleanup that rather big patch in order to more easily test which parts are the heavy ones, I don’t see anything obvious which could help you speed things up. We should probably do a proper performance analysis (using an external tool) to identify bottlenecks in either vvvv or Elementa. In case we go down that route it would help to know what vvvv version you’re using - 2021.4 or 2022.5?
Hi Elias, I’m using 2021.4 .12.
Do you think wrapping elements in class will help? I’ve understood that Group(spectral) made the job…
After some exports of your posted patch plus some subsequent performance profiler runs we managed to tweak some nodes. In total the render time went down from ~9ms to ~7.8ms, memory allocation during a time span of 10sec went down from 410MB to 240MB thereby reducing time spent in garbage collection from 140ms to 90ms. Not sure it will solve your performance issues, but call it a step in the right direction.
Here is a flame graph comparison of the main Render call.
Before:
After:
You can test these changes yourself by using the latest 2022.5 preview (>= 481) plus most recent VL.Elementa (>= 5.1.2, which by the time of writing wasn’t release yet as package - should be soon though).
Elementa 5.1.2 was just pushed, should be available via nuget install in about 30 minutes. Thanks again for the fix @Elias !
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.