Bonjour ! back after a long time and a quite to-much-moving-life…
I m continuing on my project and i m encoutering troubles of refreshement / antialising / with stride scenewindow when moving my flat camera filtered with damper.
Is there any way to fix this trouble ?
Here is a capture : https://1-0-1.fr/wp-content/uploads/2026/05/questionb-camera.mp4
Thank you :)
here is a mmore clear video of the effect. https://1-0-1.fr/wp-content/uploads/2026/05/captre-plus-claire-teraing.mp4
do you have a small patch that shows the issue ? just tested with the camera help patch and adding a damper for the initial interest doesn’t create the issue
This likely some draw call taking too much time.
The issue is likely one of the layers.
You need to check maybe you have some cpu intensive stuff that is not cached. I doubt that camera has any impact on that…
nice shot @antokhio ! completly agree, i began to work on on a a kind of is-in-frustrum function that works, but didnt changes fps. still around 15fps, and CPU is 15%, GPU 7%. maybe gamma is mono threaded ( a real doubt about it ) ?
i need to find where there is syphon effect
@lecloneur the problem is its in the all big patch trying to get some performances back, then seeig whats going on. thank you !
In my view, this is the work of the Garbage Collector or a similar process. It is highly likely — and indeed very probable — that the issue stems from a large number of objects being CREATED somewhere in every frame.
Game engines usually have profiling tools, but in this case, only a miracle and careful attention will help you.
That is precisely why it is very important to understand the essence of mutability and immutability. Try placing different parts of the application that do not require constant computation into the cache region.
@yar thank you, i will try this old-way technique. i know this way :)
nut yes cache will be the answer surely, somewhere (? somewhereS )
I have cached certain parts of the code, and used a condition (being in the field of camera) for calculations, wich improved great the all result. I was delightly surprised to have no more go and go back when filtering with mainloop, this by caching the meshruntime.
but i still have those lateral very annoying glitch while moving the camera. There is lateral bands, very strange.
here are 2 videos showing the artefact (white lines behaviour of the big tower)
-one at 30fps
-one at 60 fps
Does anyone know how i can improved and have a real smooth and not glittering movement with the stride rendering ?
using scenewindow.
Thank you
same thing with a MSAA x8 using Renderwindow instead of scene window :
ok lateral band are only in fullscreen with Gamewindow . if i put in windowed mode my output, i have no more Tearing effect
For tearing you have to go to nvidia driver and turn on VSync for for vvvv.exe or globally for a system (It’s in advanced 3d settings) I think the driver does not really respect if you have it on in vvvv
MSAA is kind of overkill technique specially at x8 I would keep it on x2 or x4 maximum
thank you @antokhio , it was the driver specifically for tearing !
i m still having some trouble with movement of cameras and contratsed element. actually set up is making like a blur, but its somehow not really convincing. i m now at 30fps.
any idea on how to improve ?
btw is there any difference between scene window and iRenderer ?
Yes there are differences between Render Window and Scene Window. Actually VSync handling is one of the known one (e.g. Render Window you have to turn vsync manually, scene window handles VSync). The SceneWindow as an actual stride game, with all the additional stuff stride runs for games… The IRenderer is more like stride rendering pipeline hack, like it uses stride graphics stuff but it does not manages anything additional for you…
The problem with blurring is likely texture sampling, like if you have assets that is size X on screen and texture that size Y on screen, if X != Y it’s a blur basically… Likely you to patch shader with another sampling technique like Lanczos https://www.shadertoy.com/view/flVGRd
If i got symptoms correct
The difference between Scene Window and Render Window might also account for MSAA to work properly.
About performance drop, you have all the tips… it’s your pipeline you have to dig it…
hum… thats true. well so i will stay on SceneWindow. already got something really better, but not so perfect. thank you @antokhio !
These aren’t frame drops. You’re seeing stutters and freezes because memory is being released and the GC is running. There are other processes that cause similar effects, but I’ll leave it at that. Imagine you’re creating 10,000 objects every frame, or, say, just one, but a very large one. And then, every frame, it changes slightly. And it’s immutable, for example. What happens? The old object remains in memory, whilst the new one is created in a different part of memory. And so on, 60 times a second. At some point, memory runs out and the GC kicks in. It starts freeing up tangled memory containing large amounts of data. This takes time; at some point, it can take up to tens of milliseconds. At that moment, the application freezes for those few milliseconds.
There is also a major issue with memory allocation, which is generally quite difficult to manage and monitor in VVVV. Put simply, certain processes temporarily occupy memory space, and clearing this space subsequently places a load on the GC. If this happens frequently, the load can be significant. Working with strings, for example, is a classic case in point. In C#, there are Span classes to work around this problem, but VVVV does not have anything similar (straight out of the box). But probably it’s not the case.
Yes, VSync is important, but it doesn’t solve the problem of freezes and stutters. Yes, it would be good to check whether everything is running on the correct graphics card. But most likely, your problem simply lies in the application’s architecture. Carry out a thorough refactoring, keeping in mind the memory layout and how the Garbage Collector works. Just have a chat with a neural network about this; it will give you a huge boost in understanding the problem.
Unfortunately, unlike some game engines, as far as I know, VVVV doesn’t have profiling tools where you can clearly see where CPU time is being spent and what is causing the freezes and stutters. Perhaps there are third-party tools from the C# ecosystem, or Stride might be able to help with this.
@yar thank you but i have no more go - go back effect from garbage collector of ensure value consequences. its ok now with mainloop.
µits more actually a question quality of movement and how if affect the sensation of the image at 30fps. not sure i can reach a 60fps, real doubt about it.
@karistouf You’ve misunderstood me
If you were experiencing frame rate drops before and you’ve fixed them, that’s simply a side effect of the optimisation.
But what I’m telling you about stutters and freezes is a clear symptom linked to GC. That’s because GC operations won’t be reflected or taken into account in the main loop timer. It all happens in different threads; they even have different access levels – they’re simply on different levels.
I’m not just saying this for the sake of it when I mention profiling tools. Without them, it really is very difficult to identify such issues properly. The MainLoop node alone won’t help here.
Excuse me @yar, I had to use a translator. Yes, I understand. I was talking about the main loop because I was very surprised (before optimization) by these back-and-forths related to the garbage collector when the main loop was implemented. Currently, with or without the main loop, I’m getting around 30fps without side effects. But yes, the problem isn’t solved, that’s for sure. Getting to 60fps would be best in terms of image quality, but I’m having trouble seeing how, or I’d have to redo a lot of things that seem to be working, without any guarantee of a completely reliable result after disassembly and reassembly.
I’m trembling with worry… Thank you.
All right.
Let me reiterate this to make it clearer. Frame rate (FPS) alone does not indicate whether or not the problem you are experiencing exists. If you’ve had FPS issues in the past, this actually indirectly supports my theory.
You might have a low FPS, but the app doesn’t stutter or freeze. You might have a high FPS, yet the app still freezes and stutters.
And yes, you’ll probably need to redo everything, planning the app’s architecture much more carefully. That’s just part and parcel of development.
In future, I’d advise you to pay close attention to how mutable and immutable objects behave, to keep a close eye on what happens in every frame, and to be mindful of creating objects that trigger memory allocation. Try feeding my comments (or our dialogue) into a neural network and discuss the intricacies of memory management, what the best and worst practices are, and how best to apply them in the context of VVVV.
Yes its very clear @yar. I have some suspicions. Especially because in my model of layers i have embedded sequencers for recorded or live animations. This maybe a good base of discussion on the reformat if this if i got your point
