I agree with the solution suggested by Bodysoulspirit. But I suspect that unnecessary "get image size" node are triggered anyway in his schema, even when resizing is not required, every time a new frame reaches "Blend images" node. Probably "get image size" is much less computational requiring than "resize image" of course, but it's possible to skip it also. Moreover, "resize image" also is always triggered whenever the new frame has different dimensions.
This way should improve the solution, triggering "get image size" and "resize" just when strictly required (caveat, not tested):
I don’t think this is a feature request type scenario in that there is no way to render movies and have a workflow where the user is previewing the output they are going to get. Does it really make sense to open it up to voting whether or not the window should match the dimensions being sent? Or is this just a bug? Maybe you all are right though, just throwing that line of thought out there.
The QCTV code example has cocoa based code that shows how this could work.
But also, can’t the window spawned just match the texture size it is being sent? There doesn’t even have to be anything fancy if the output window just went ahead and matched the input res when the composition is initialized. I think it is arguably bug-like behavior that it is currently somehow arbitrary.
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.