Here are the lists...

@john_dennis Thanks for testing all those. I'm seeing the same with Black Restore. I wonder how that one escaped.

Then we need to list, a) FX that can cause transparency, and, b) FX that can't. Then we can ask the developers if the underlying tracks can be ignored if the FX on the overlying track/event(s) are all from list (b). To my mind, just an extra bit of conditional logic in the code, with a huge benefit to playback smoothness. I will make a start on such lists.

Thanks for cracking the nut guys! Did you try Event-FX also? note to myself: must check..

Yes. Event-FX also causes the unnecessary slow-down.

I think it should be a possible e to create a logic where a clip is tested for opacity, and if the answer is 100% the rest of the processing can be skipped..but maybe I'm naive in thinking that; That could be an easy way out having to blacklist individual FX...

An opacity test would be ideal, if it's not counter-productive by being heavy on processing power. I was thinking that a "blacklist" might be simpler and "lighter" to implement, but would be more feasible for VEGAS-native FX. I'm counting 76 of those in VP17. And then there's VEGAS Effects and 3rd-party FX. But one step at a time.

I have a nagging suspicion this issue was there five years ago and is still there today.

@AVsupport  @NickHope

Good find. I also had a feeling this had been raised before. Will read that and do some further tests myself, but might not be today.

I've read the old thread. As the thread goes on, most of the discussion regards whether the underlying events are ignored depending on whether the overlying events truly fill the frame. The discovery that simply having an FX on the overlying event, whether transparency-inducing/crop-inducing or not, seems to be new. Possibly simpler to fix programmatically too.

These are the VEGAS native FX that can cause transparency:

• Bezier Masking
• Border
• Chroma Keyer
• Color Corrector (Secondary)
• Cookie Cutter
• Crop
• Deform
• Glint
• Layer Dimensionality
• Lens Correction
• Mask Generator
• Mesh Warp
• Mirror
• Picture In Picture
• Rays
• Soft Contrast
• Stereoscopic 3D Adjust
• Video Stabilization

These are the VEGAS native FX that can't cause transparency. No need to consider obscured events in the compositing calculations due to any of these being applied to the obscuring events:

• Add Noise
• AutoLooks
• Black and White
• Black Restore
• Brightness and Contrast
• Broadcast Colors
• Bump Map
• Channel Blend
• Chroma Blur
• Color Balance
• Color Corrector
• Color Curves
• Color Grading
• Color Match
• Convolution Kernel
• Defocus
• Dual Fish Eye Stitching
• Fill Light
• Film Effects
• Film Grain
• Gaussian Blur
• Glow
• Gradient Map
• HSL Adjust
• Invert
• LAB Adjust
• Lens Flare
• Levels
• Light Rays
• Linear Blur
• LUT Filter
• Median
• Min and Max
• Newsprint
• Pinch/Punch
• Pixellate
• Quick Blur
• Radial Blur
• Radial Pixelate
• Saturation Adjust
• Scene Rotation
• Sepia
• Sharpen
• Slow Motion
• Smart Upscale
• Smart Zoom
• Spherize
• Starburst
• Swirl
• Threshold
• Timecode
• Tiny Planet
• TV Simulator
• Unsharp Mask
• Vignette
• Wave
• White Balance

I'm not sure about 360° Stabilization. I got hangs when I tested that one.

Obviously there are other reasons that the underlying events should be considered in the composition calculations, for example a compositing mode other than Source Alpha, a Composite Level Envelope, an opacity envelope at less than 100%, track motion and event pan/crop.

I can compile a list of Hitfilm Ignite.. mind you that's also quite a few 130ish, Filmconvert and some Newblue FX, but I'd prefer to know if that's worth the effort before going down that road..

I can compile a list of Hitfilm Ignite.. mind you that's also quite a few 130ish, Filmconvert and some Newblue FX, but I'd prefer to know if that's worth the effort before going down that road..

I don't think it's worth the effort at this stage. I think we should see if there's any interest from the VEGAS team in changing this behaviour first. I'm intending to raise it with them within the next couple of days.

I would appreciate that if you could @NickHope I really think this would make a huge difference in playback performance. Any chance to mention the missing-buffer-look-ahead-frame-dropping-between-cuts issue in that sitting would be awesome!

I would appreciate that if you could @NickHope I really think this would make a huge difference in playback performance. Any chance to mention the missing-buffer-look-ahead-frame-dropping-between-cuts issue in that sitting would be awesome!

Can you link me to discussion about that please?

have a look at this VP16 thread a little while ago you might remember @NickHope .

The problem hasn't really gone away yet as @john_dennis was saying, even though many improvements have been made. Could be related to XAVCS codec and FHD preview and VP RAM management, who knows. Maybe it's the old Commodore64 core code ;-)

For want of doing something useful until I have to go shoot at 1100, I reconstructed my previous test to run on Vegas Pro 11-701. The machine is so old that I couldn't use preview performance for comparison for a UHD project. Rather, I used render time to a Mainconcept AVC Internet template customized to output UHD. The main video track had a slight Color Curve fX added to brighten the video. Here are the times to complete the renders.

This phenomenon has been around for a long time and is likely architectural or well-baked into the Vegas code.

forgot to add the link to the previous discussion to issue 2 with VP16:

https://www.vegascreativesoftware.info/us/forum/vp16-248-307-update-general-timeline-playback-performance--112580/

Thanks @NickHope for putting so much effort in making a better Vegas for all of us!

Nick, how about MUTED events?

muted events [muted tracks that is] don't effect timeline playback performance AFAIK