The problem is that my patches framerate drops every 4 seconds for 1 second. Most of the time the framerate is half of its original…120 drops to 60… or 60 drops to 30…
…i start the patch and everything is fine…After a while it starts to behave like this
I am not able to spot a problem in TTY.
I am not able to see this behaviour in the debug timing mode.
A more complex patch does this more often then a less complex patch. The attached small patch showed this behaviour on my machine every now and then…like i said - i cant force it to show or no to show…
everything together sound like memory is running full and beeing released or sth. But to be honest i have no clue!!!
Does anyone experience this problem? Please help me out!
thx for taking a look so fast!!!
the rythm described with 4 seconds to 1 second is sth. i only had with a more complex patch… and yes i do feel that there is sth. about those framebuffers…i work on a projection mapping project…which has plenty of rendered masks and content in plenty of temptargets…this might increase the weight of this problem…
anyway im really happy to see im not crazy…;)
having this problem since 3 month…i finally reach a point where i cant proceed anymore since it drops from 25 to 10
@readme)) found out that ((node:Queue (Spreads) is one culprit for these framedrops. exchanging the node with the legacy delphi one completely smoothed out the fps.
and the issue is most probably garbage collection
FYI, the queue was not in mios demo patch before. thats something I added, it did not influence the problem in question. New thread?
I strongly suspect it is because of internal conversion of transform matrices in the Quad (DX11 Layer). If you use a different shader it behaves smoother(for example if you use Constant and a Grid geometry), but of course also slower.
i added a patch, that takes advantage of instancing your grid geometry. it is both faster and seems not to glitch as much.
velcrome’s suspicion proofed to be correct - the quad node made a complete copy of the transform input which in case of 20000 matrices leads to an array allocated on the large object heap only collectable by the garbage collector during a gen 2 collection (the most expensive one) which in turn leads to the seen framerate drops. a pull request for the dx11 repository addressing this issue is already in progress.
wow everyone this sounds very nice - i give it a try… @verlcrome thank you very much…your patch is very good to learn for me- THXXX!!!
however - i do think that by accident my testpatch distracts from my original problem lol …i patched together this patch with the quads just to stress vvvv - my bigger more complex patch doesnt even have big spreads of quads but way bigger drops of framerate…but what it has is a lot of different content rendered in temptargets by the use of quad layers…i will try to relace those quad layers with quad geometry and constant and see if this helps…again thank you very much for taking your time
yes, you might be right, your problem does go a lot deeper, because it involves the Garbage Collector of .net. Recurring spikes in the framerate are a common symptom of that.
Because in c# memory cannot be programmatically cleaned when it is no longer needed, every plugin has to use as few short-lived objects as possible. Object recycling is the usual way to deal with the fact, that the Garbage Collector is not primed for any real-time stuff. But that’s “new thread” material again.
more to your problem, you could try two things to avoid unnecessary renderers.
in my main patch 15 layers are combined by the group node…i added renderstate - blend - add to that group…i turned it off and it runs smoothly since 2 hours. maybe there is a flaw about blend…defintly will check the behaviour of my dynamic buffers too…Thx everyone for taking a look