As it is impossible to keep a descent framerate while using vvvv IObox for GUI, I’m now trying to work with two instance.
So, one instance contains GUI elements, the other instance contains the whole system. I was thinking, yeah now I can play with vvvv slider and button without affecting anything on my second instance.
In fact, no… I don’t know why but if the GUI instance is active, the other one has its FPS divided by two, even with mainloop node set to 120.
ok so, I found something randomly. I have two renderer on my render instance, one for preview, one for final visual, and if the preview is closed, then the mainloop node seems to do the job. XD
is it?
just did a quick test and did not notice such a thing (frame rate division by 2). but my test patch was rather simple - don’t know how it behaves with complex stuff.
how do you exchange data between the two instances? shared memory, OSC?
and i assume you set the mainloop foreground and background FPS to the same value.
do you have a demo patch to demonstrate this behaviour?
I use sharedmemory but that’s not the problem.
Mainloop is set 120FPS for both.
I can’t send a demo patch, as it is a big project, called C-MiX ;) and the main trouble since I started clonemixer, is to have a damn GUI working without problem…
can’t say this often enough, just stop using vvvv’s gui elements to control stuff during runtime, they are like constant values in computer code, only to adjust and tweak the software while developing it. they are never meant to be the GUI. make a simple renderer and use Gui2D or any other DX based UI framework…
I tried SetAffinityMask, it just tell me “FAILED” all the time.
I tried to set the priority manually on the task manager. Nothing change.
If I have only one renderer (the final one) and do not use the second for my channel preview, the mainloop seems to work “almost” correctly.
But even with two instances, if I manipulate a lot the GUI, then it slow down the other one…
This is such a nightmare.
The vvvv IOBox is really handy to prototype GUI since you can use the mouse to quickly organise it. Creating buttons and sliders is easy. I found that using CreateEnum is also a good trick to make some kind of dropdown menu. Too bad, while we can setup the text size in the IOBox, the dropdown enum window can’t be changed…
Now I’m using “Message” from Velcrome and it does a perfect job to send data over the application and save GUI parameters in a file. This is how I send all the data from the GUI and it is one of the best contrib so far(which should be included in addonpack in my opinion).
I tried catweasel’s contrib for GUI (and every other GUI contrib), this is definitely not what I am looking for because using Text node to make GUI eat a lot of ressources. I have many effects name, doing it this way kill the framerate while loading text.
Also, using rendered GUI take so much time to create and to place 2D elements in the renderer. Indeed the only choice in this case is to use transform 2D and the XY input pin to control the position of every elements… Try to align anything then…pure waste of time. And if you want to change the layout, you have to change every Transform2d XY input pin one by one…
Is there anything I can do, or maybe one of you guys has some experiences with this ?
How about sprite sheets for text? You could easily do the transforms in shader and instance all the text. There is a new version on my Gui in the works, just need some time to tidy it up a bit, I’ve always found GUI’s take up too many resources, so the new one runs in a separate instance too. I sometimes limit the mainloop of the gui too, the other instance seems to run almost as fast as with out the gui on the whole.
Do you need to have run vvvv as admin to set the affinity? I’ve done it without errors…
I have also made a dropdownmenu for gui’s maybe adapted for sprite sheets it might be faster?
if that would be the case, you would need to highlight a difference between runtime and dev time. in my understanding, the current gui is simply a shortcoming to the grand vision, that there is no such difference, and that the code CAN be the gui at the same time
ps: a (presumptious) solution would be to put ioboxes in their own thread
globally i would say that something changed in beta 33.3 from 30.2. like the performance was less for screen refreshment.
for example i m using the echo fx, and despite its a strong effect, its not really consuming a lot of ressources, with beta 33.3 IT IS.
i m making comparison on a hudge patch between 30.2(creation) and 33.3(touring) and the fact is 33.3 is viciously and asycnhronally less ressourcing ( not the same drop-frame result each time for same effects)
Now I’m using Winforms to make my GUI, ulgy, but it should work. Problem is, I can’t use the FormDesigner with a vvvv plugin, so I need to design and copy past code to the plugin’s code…
Next problem is, when I open a filedialog or open a combobox, vvvv freeze… so I’m thinking : “use a second instance!”
Yeah sure !, but when I’m using two instances, I have the framerate problems described above, so my render instance doesn’t keep it’s framerate anyway.
As you can see on the screenshot above, I’m not trying to make a really complex GUI. Few buttons, some kind of combo box and color picker, very simple. This is why I made it with vvvv IOBox.
just to be sure, youve got background fps set as well as foreground?
Can you set affinity? Does it help if you run setup and vvvv as admin, if it doesnt? I use mine set to 3 cpu1+2 and 12 cpu3+4.
does boost node do anything?
present upfront?
Or increase timer precision on the output instance?
Are you texture sharing? Does it affect the frame rate if you don’t?
@Cat
background and forground same with 120FPS
I tried affinity, nothing really different or maybe I’m using it the wrong way.
Boost, same.
What is present upfront ?
Or do you inscrease timer precision ?
I don’t do any texture sharing, just share value from the GUI.
@elektromeier
Filedialog is the one I’m using now, when I tried to code the GUI with WinForm, I was thinking going full. Means no more vvvv GUI elements so it’s easier to keep everything tight.