Periodic Check Image URL Events seen / frame drop

[Bodysoulspirit]

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.

Other notes

• Vuo version: 2.0.0-beta4
• macOS version: macOS 10.13
• How severely does this bug affect you? It’s annoying but I can work around it.

Periodic Check Image Events.zip (3.84 KB)

[cremaschi (mic)]

I got the same hiccup; gone away introducing a different source for events that load images. Try this:

 

[cremaschi (mic)]

Another possible solution, with a “Spin off event” technique:

[cremaschi (mic)]

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.

[Bodysoulspirit]

Thanks @cremaschi, 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  

[jstrecker (Jaymie)]

A question to Vuo team. Why does this comp show the hiccup as well?

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 from Fire on Display Refresh shouldn’t be be stuck/dropped since the subsequent image loading is done on a separate event stream (Spin Off Event).  

[cremaschi (mic)]

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.vuo (3.73 KB)

[cremaschi (mic)]

Is there a specific format Vuo website accept for videos? My upload doesn’t seem to work one uploaded.

[jstrecker (Jaymie)]

Dear, I agree with you but I think there’s a bug that makes behave different than expected.

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.

Is there a specific format Vuo website accept for videos? My upload doesn’t seem to work one uploaded.

The format you uploaded is supposed to work, but it appears to be broken on some Chrome versions or Chrome + macOS combinations.

[Bodysoulspirit]

Mic’s solution to use a Spin Off Event doesn’t’ work for me, nor when using a second Fire 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.