Hello, hoping someone can compare their experience playing back HAP-encoded content in Vuo 1.2.8. I'm finding that Vuo appears to be using CPU for HAP playback on the two systems I have available to test (MacBook Pro with dGPU running 10.13.6 and Mac Pro with GTX 1070 running 10.12.6):
Pretty simple to reproduce, using "Play Movie" node with HAP-encoded movie file as input, then seeing these results on the MacBook Pro:
CPU usage for 2560x2560 HAP-encoded playback: Vuo: 250% VLC: 70% QC with the CoGeHAP Player: 25%
For 1080p content: Vuo: 100% VLC: 35% QC: 15%
Video files are encoded with Apple Compressor, AVF Batch Converter, QuickTime 7 Pro, no effect on the issue. This is my first attempt at using Vuo to replace some utility QC compositions, hopefully I'm missing something or having an issue unique to my setup.
Had a MPB 13" 2018 Intel 650 macOS 10.14.3 in the hands and ran some tests too.
• Basic load 3D models works. The Tile Starfield example composition for example is fine.
• Sample comps that produced glitches : Dent Room (displace 3D object with image node I guess), Pinch Rectangles, Pinch Sphere, Rewind Checkerboard Explosion.
• Comps that outputted black compositions screen : Divide 3D sphere, Facet Sphere
Quite astonished to read that the only fixes for openGL would be to run in on the CPU instead ! Really ? No other methods ? Amazing. I guess the team also has to keep in mind all the other maybe-related sub-bugs they fixed in the past like for the Add Noise to 3D objects etc. A bug fix for this should not break the already fixed bugs. However I remember some of the bugs were fixed to work on older GPU's like the Intel HD 3000? if a choice had to be made I guess recent GPU support would be better than older ones though ?
Anyway, one question, before moving Vuo completely to Molten / Vulkan / Metal which I assume will be some work, would it not be possible to test it out for small fixes like these first ? I mean to still have OpenGL but start using Vulkan in parallel only for some nodes like these ? Just a non-coder question.
Jaymie, thanks for clearing it up. yes, to try the hardware before getting it would be probably the best option.
Anyway, I think i will just wait for the future fix. Hopefully implementing Metal will fix. Thanks!
This is not a bug. On nodes that have one input port and one output port (like Fetch Image) we show the input port label, but not the output port label, so one port of the node is labeled. On nodes where there is only one input port and multiple output ports, you don't really need a label, since you can get the input type from the documentation if you don't know it. On those nodes we omit the input port label to keep the node an uncluttered as possible.