Cyclic Framerate Drops

Hey there i have a problem with framerate.

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!

im on:


PerformanceTest.v4p (27.8 kB)

hi mio,

i can partly confirm this problem, but I do not get 1sec breaks every 4 sec, it is more like one frame out of 4 that takes about twice as long.

what is interesting is that if I reset one of the Renderer (DX11 TempTarget) it is smooth for a short while.

I tend to agree with you, that this is a memory issue, looks like the garbage collector is collecting.

hey velcrome,

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

again thank you


btw you could have told me that its you!!!..hehehe thx marko

@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

@woei interesting. can we have a clean demopatch for this?

@joreg ask readme, not sure if he’s back from ny yet

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.

PerformanceTest.v4p (35.3 kB)

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.

regarding the queue open a new thread pls.

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.

  1. move to pixel shader like Blend (DX11.TextureFX) or Mix (DX11.TextureFX) to do masking.
  2. enhance your masking with DepthStencil and feed your content layer together with your masking layer into the same renderer to save render steps.

Indeed there was an Extra ToArray() involved, this is now fixed for next release.

Also DynamicBuffers got a speed up on the occasion (even tho they do not suffer from the GC issue, since they keep internal buffer).

As a side note, this would be a good exercise to use a compute shader instead, guesstimate = 10 lines of code ;)

i might solved my problem…

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


Using blend states can largely affect your fill rate, hence why it’s disabled by default in dx11.