Preview Display Image 640x360x32. What does it look like fullscreen with a bigger image?

@john_dennis and @EricLNZ  Here are the two larger images. It appears that during the render, despite what the "Display:" setting is reading at the bottom, it's lying -- clearly the image I'm seeing during the render is much smaller than the image which appears in the preview window when it's not rendering.

Image in the Preview window when I'm not rendering:

Image taken during the render:

I don't think this is relevant, but I'm rendering using MAGIX AVC/AC MP4 (Internet HD 1080p 29.97 fps (AMD VCE)

@RedRob-CandlelightProdctns

If you want the preview to closely match the rendered output, Good/Full is not going to do it. Change your Preview setting to Best/Full to get rid of the jaggies. Display FPS might be below full frame rate, however.

At render time the display setting is ignored.

Does it matter?

I thought to stop resource conflicts the GPU isn't engaged in the preview window at time of render, so perhaps it's downsized in the interest of speed. Not sure, I often render with the preview off entirely.

@RedRob-CandlelightProdctns

If you want the preview to closely match the rendered output, Good/Full is not going to do it. Change your Preview setting to Best/Full to get rid of the jaggies. Display FPS might be below full frame rate, however.

At render time the display setting is ignored.

@john_dennis I realize that -- this isn't an issue with the preview window. It's an issue with what the preview window looks like *while rendering*. My preview window *is* set to best/full --- WHILE rendering, it also shows "best/full", but has that jagged issue.

If it doesn't affect the render and only happens while rendering, is it really an issue?

Does it matter?

I thought to stop resource conflicts the GPU isn't engaged in the preview window at time of render, so perhaps it's downsized in the interest of speed. Not sure, I often render with the preview off entirely.

@RogerS and @DMT3 This came up because WHILE I was rendering I noticed how horrible that graphic looked -- so I cancelled the render and it looked fine on the preview then. So I did a test render and the actual output also looked fine... which led to this post. Ultimately if the rendered output is proper that's what matters most -- but as I'm sure there are lots of folks who will spot-watch the preview during a render to make sure things are going well.

It's an issue of confidence. I've always understood the preview during render as an indicator of what the final output will look like -- effects are displayed, all compositing is shown, etc.

That's actually saved my butt more than once -- like when Boris/Mocha needed to "initialize" and the "initializing" message literally popped into my output if I hadn't visited that region of the timeline before rendering.

There are a few issues that clash:

• Preview quality
• Preview speed (f/ps)
• Render quality
• Render speed (is raised to a religion by some here)

My (already deceased) mother used to say: "You can't get all nine together"
Well, there are only four here.........

@walter-i. I understand all that (thank you).. think you may have missed something through.

This is not a question of "why is it jagged or not scaling my preview output when display is set to preview".

During render, display shows best/full. But what I'm seeing is it is scaling weird and not actually showing the text as looks when the render file is saved/played.

I will repeat this in an older versionbof Vegas to confirm it is a new problem.. been using near-daily for over 12 years and never observed this issue.

@RedRob-CandlelightProdctns

Two data points:

Vegas 14

Vegas 19

• Text generated in Photoshop, saved as a transparent .png and not scaled in Vegas.
• Rendered to Mainconcept Internet HD in Vegas 14 and Magix AVC Internet HD in Vegas 19.
• Preview display area held to 1280x720 in both programs.

I find the displays at render time to be identical for this test.

@john_dennis  Two things....

1. THANK YOU for doing that .. looks like 14 and 19 are both doing that poorly 😔

2. It appears I was less observant back then?

3. is that trailing comma grammatically, correct? 😉

1. Vegas isn’t doing poorly, I zoomed in with Photoshop.
2. Maybe.
3. Likely not. You should see some of my passwords.

During render, display shows best/full. But what I'm seeing is it is scaling weird and not actually showing the text as looks when the render file is saved/played.

During render, graphics resources are diverted to the useful purpose. The most efficient render would occur if the display window and GUI were turned off completely, such as VideoRedo has always done.

I rarely watch renders.

During render, display shows best/full. But what I'm seeing is it is scaling weird and not actually showing the text as looks when the render file is saved/played.

During render, graphics resources are diverted to the useful purpose. The most efficient render would occur if the display window and GUI were turned off completely, such as VideoRedo has always done.

@Musicvid is the difference measurable and significantly noteworthy? Maybe I'll consider that more closely!

@RedRob-CandlelightProdctns

"... is the difference measurable and significantly noteworthy?"

A little less than 8% for one of my projects.*

* Two Minute 1080p timeline rendered using Voukoder CPU render.

@RedRob-CandlelightProdctns Most editors that I"ve seen don't update like a timeline preview screen, because it's robbing processing power, potentially increasing render time. In this example 'minimal' is the standard, and I think should be the standard for Vegas also, but have an option to turn on 'real time' preview on the fly where necessary

@RedRob-CandlelightProdctns

"... is the difference measurable and significantly noteworthy?"

A little less than 8% for one of my projects.*

* Two Minute 1080p timeline rendered using Voukoder CPU render.

Not insignificant at all.. nice! Just closed the preview window before rendering?

hmm.. why would disk usage in your 2nd render (no preview screen) be higher?! Same CODEC and same project should have been identical disk usage.

@RedRob-CandlelightProdctns, if you have SoundforgePro or ACIDPro, you will see their video preview window works in "Integral Stretch".

The VEGAS preview window works in two modes: seamless scaling by editing and integral stretching by rendering.
Integral Stretch of 16:9

128x72
256x144 
384x216 
512x288 
640x360 
768x432 
896x504 
1024x576 
1152x648 
1280x720 
...

@RedRob-CandlelightProdctns, if you have SoundforgePro or ACIDPro, you will see their video preview window works in "Integral Stretch".

 

The VEGAS preview window works in two modes: seamless scaling by editing and integral stretching by rendering.
Integral Stretch of 16:9

<snip>
...

That would explain the quality difference on some of the preview elements I'm seeing during the render -- you're saying Vegas uses one method to scale and display the preview window during most operations, but while rendering is going on the preview screen is drawn using a completely different method (integral stretching)?

How can you tell which method they're using to scale?

That's one window, multi-tasks.
Or you can imagine they are not the same window, but looks the same out.

1. the timeline preview window (seamless scale). Signal comes first to your view settings and then image scales max to the window area you defined.
   
2. the Trimmer window (seamless scale). It works exactly like above, only signal comes from another "timeline".
   
3. the render-view window (you can leave it empty by preferences setting). It selects the most suitable integral size to the area you defined; it's the simplest one, resource saving and only show every 5th image - my defined area is just one of the integral size thus no change.
   
    

e.g. your defined area is 1280x718, then by rendering the integral szie comes to 1152x648 or so.