Status:
Vuo version:
OS version:
- macOS 10.13
How severely does this bug affect you?:
●●○○ — It's annoying but I can work around it.
Steps causing the bug to occur:
Not sure this is a bug, or related to to my old hardware.
I want to check every 0,5 seconds if an image has changed, load it, and apply a rotation to the layer.
It has an Allow changes
after the fetch image to update events down the node chains only if the image changed.
However, on the rotation animation, I'm seeing a frame drop every 0,5 seconds, from 60 to +/- 55 FPS.
Since I have an allow changes node that block events, I guess the choppy rotation is because of the frame drop from loading the image into the composition ?
Is it because of my hardware ? Or something else ?
Thanks
Have you found a workaround?:
Nopynope. Since the image name stays the same even if the image updates, I don't know how to load the image into the composition only when changed.
Screenshots:
Compositions:
Attachment | Size |
---|---|
![]() | 3.84 KB |
Comments
I tried loading a 200mb image
I got the same hiccup; gone away introducing a different source for events that load images. Try this:
Schermata 2020-01-18 alle 10.17.01.png
Another possible solution,
Another possible solution, with a "Spin off event" technique:
Schermata 2020-01-18 alle 10.24.12.png
A question to Vuo team. Why
A question to Vuo team. Why does this comp show the hiccup as well? My guess is that it shouldn't, as "allow first event" clearly stops all incoming event after the first, so "make image layer" evaluation shouldn't be delayed.
Schermata 2020-01-18 alle 10.44.51.png
Thanks mic, the workaround to
Thanks mic, the workaround to use fire on start + fire periodically works.
So the problem does not seem to happen because the image is being loaded into the composition I guess.
Mmm, problem is for image protocols you should use "Allow Periodic Events" instead of "Fire Periodically" (for example for screensavers).
But solves my problem for now ;)
Tnx
A question to Vuo team. Why
I would expect that composition to hiccup only at the beginning. The second event from
Fire on Display Refresh
will be stuck waiting (or dropped, depending on the trigger's setting) until the first event has finished loading the image. After that, events fromFire on Display Refresh
shouldn't be be stuck/dropped since the subsequent image loading is done on a separate event stream (Spin Off Event
).Dear, I agree with you but I
Dear, I agree with you but I think there's a bug that makes behave different than expected. It's clearer loading a heavy image and with longer periodic event. Here is my comp and a demo video: as you can see, seems "make image layer" is awaiting for the spin off event also to execute.
bug.mov
Bug.vuo
GA_0001.jpg
Is there a specific format
Is there a specific format Vuo website accept for videos? My upload doesn't seem to work one uploaded.
Dear, I agree with you but I
You're right, it is a bug. Having the
Allow First Event
in that particular spot causes the event streams to be tied together (one waits on the other) when they should be independent.The format you uploaded is supposed to work, but it appears to be broken on some Chrome versions or Chrome + macOS combinations.
Same when using Execute Shell
Mic's solution to use a
Spin Off Event
doesn't' work for me, nor when using a secondFire On Display Refresh
node.So the only fix for me now is to use a
Fire Periodically
, but not ideal I guess for protocol mode comps.