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)
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?
Or increase timer precision on the output instance?
Are you texture sharing? Does it affect the frame rate if you don’t?
background and forground same with 120FPS
I tried affinity, nothing really different or maybe I’m using it the wrong way.
What is present upfront ?
Or do you inscrease timer precision ?
I don’t do any texture sharing, just share value from the GUI.
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.