Just noticed that if you scroll the Receive String list in Inspektor it freezes any renderer output while scrolling. Is this intentional? Seems like a bug to me, since I havent noticed it with other interface elements, except for any save dialog, which results in the same freezing of the renderer, which is equally annoying for live-coding.
I have tried this just now with an R (Value) node and a DX11 renderer. As soon as you let go of the scroll bar the renderer continues.
that is because all of vvvv runs in only one thread. while the gui is blocking the mainloop nothing else can be computed. there is no workaround on your side but we’ll have that fixed one fine day.
After a really long day (2 a.m.), looking at our project, trying to understand VL and taking first steps, Sebastian pulled me over to his desk, saying “hey, I’ve got to show you something”. And what I saw was a prototype of v4 running on multiple evaluator processes. I was baffled.
After that, Elias took over and showed me a v4, where the interface was running in a separate thread. Rendering unimpressed by UI interactions.
We talked for a very long time. And for both of the prototypes there are very good reasons, really severe problems, why they are not a reality yet; and probably also never will be
So until the group makes some kind of official statement people will keep asking & guessing. Limbo.
It kind of makes sense, but then there are plenty of GUI interactions that don’t cause any blocking of the mainloop. So this is only referring to somehow native windows GUI elements?
I am sure they could make a scroll dropdown that doesn’t rely on any windows GUI elements, but okay, I guess there are more important things to work on.
But yeah, at least all the GUI running in a separate thread would be nice.