Regarding “scrolling the editor is laggy”, is it smooth for small compositions, and only laggy for large compositions? Or if not, when do you notice it the most?
Regarding “receive composition frame turns the fans on”, are you saying that every composition is using a lot of CPU time (I’d be surprised since your computer is faster than mine, and Vuo’s example compositions rarely use much CPU on my system), or does it depend on what nodes are in the composition? Maybe there is a specific node that we could optimize?
We’re constantly working on live-coding performance improvements; you should see a difference in the upcoming Vuo 1.1.0 release.
Thanks for mentioning that example. It’s odd that it’s using over 100% on your system. (Curious, what is your GPU model?)
That particular composition isn’t designed as efficiently as it could be — instead of querying Check Mouse Status every frame, it could use Receive Mouse Moves which only fires an event when the mouse actually moves. We’ll get that fixed.
On my system, it uses about 35% CPU. I was surprised to see so much CPU taken just from rendering the one layer every display refresh, but it looks like that’s the base cost, and adding more layers to render is not so expensive (adding a couple additional Make Text Layer nodes, CPU only went up a few percent per layer).
In general, we’ve put a lot of effort so far into making Vuo compositions execute as fast as possible, and haven’t focused much on energy efficiency / avoiding doing work unless absolutely necessary. Improving energy efficiency is on our radar (especially when we start working on support for mobile devices).
Thanks for clarifying. I ran some performance profiles on those 3 compositions, and filed a few internal bug reports toward improving CPU efficiency for them. Tentatively planning to dig into that just after the Vuo 1.1 release.
Perhaps change this discussion name to something like “High livecoding CPU usage when using the requested frame output” as that’s what it is finally about it :)
I’ve been using Vuo on another computer this Week and I had so much fun using it without the fans on that I thought I should document this bug a little more.
So when my MBP 2011 uses frequently updating nodes it gets a high CPU usage and the fans turn on for the whole time of use.
So this is not a specific bug to the “Show mouse position” example composition.
usually when any of those high frequency events/nodes are used this happens. Those nodes/events for example are:
- Requested frame from Render X to window (to a curve time input for example) .
- Capture Image of Screen.
- Play Audio File.
- Receive Live Video (Connected to the iSight)
However it does not happen when no “Render X to Window” node is used. So if no Window is piped-up, like the “Play Audio File and Loop” example (stays at 20% CPU).
Happens on my 10.9 session just like on my 10.10 :(
I don’t know if it’s my computer only. No similar bug reports from other users ? Maybe I should clean the fans or replace the cooling hardware part ? Not sure …
I’ve attached several screenshots and a composition (with Karl Henkel’s Date and Time and Satoshi’s append zeros Nodes), other screenshots are from the the “Show Live Audio Trail” sample composition. Inlcuded also are screenshots from the idle computer monitoring and screenshots from Vuo Loader measurements as well as exported apps.
I get 70% CPU and 4100 Fans RPM here but sometimes it goes until 90-100 CPU %
PS : The MBP 13" 2011 only has one fan, so the other is not broken ;)
323 % for the “Add Noise To Clay” sample composition :(
BTW this is the graphic card :
Intel HD Graphics 3000 :
Jeu de composants : Intel HD Graphics 3000
Type : Processeur graphique (GPU)
Bus : Intégré
VRAM (totale) : 384 Mo
VRAM (dynamique, max.) : 10
Fournisseur : Intel (0x8086)
Identifiant du périphérique : 0x0126
Identifiant de révision : 0x0009
In Activity Monitor, select the AddNoiseToClay process, then select View > Sample Process
Save the result and attach it here
That may help us figure out what’s going on.
In that composition, Vuo is applying GPU-based mesh filters. Unfortunately the Intel HD Graphics 3000 GPU isn’t very powerful, so it may be resorting to using the CPU instead of the GPU, which really slows things down. In Vuo 1.2, we’ve already made a bunch of CPU and GPU performance improvements, so that may help with some compositions. But for graphics work we recommend using a system that has a discrete GPU (most recent Macs include a discrete NVIDIA GPU).
Thanks for the time sample. I skimmed through it, and, yes, it appears that the mesh filters that are supposed to be running on the GPU are falling back to use the CPU instead (which will be much slower and, of course, more CPU-intensive).
We don’t have an Intel HD 3000 system to test with. We do have a few Intel HD 4000 systems, and I just confirmed that AddNoiseToClay is not falling back to CPU on that system configuration.
I’m not aware of a way to figure out why it’s falling back to CPU on Intel HD 3000 or what we can do to stop it. The only Apple documentation I’ve found is QA1502, which just says it switches to CPU “when the hardware resources are not sufficient for a given operation”.
Strange thing. Ok. I this Macbook Pro 2011 is garbage ;)
Sad cause I can’t afford a new one now and that CPU/Fans stuff is weird to work with (because of my brushed hairstyle for example ;))
But as said, perhaps the computer itself has got a problem !
I’ll see ! And I’ll see how the next versions of Vuo will run. Sometimes, I believe that computers act funny. You change a tiny thing and it behaves a lot more different, sometimes even without purpose ;)