Patch should be ready for review.

There is one TODO left:
With multiple previews in workspace that have different preview size, which size(s) should we use to build proxies. I would like to hear your opinion here.

For the Automatic, maybe it would be useful to add to the new "Use Proxy" checkbox in Preview, a check for all strips in timeline, if any of them are missing proxy files at the current proxy resolution, then render them automatic.

Imo, it is overkill in the Automatic setting to render for all proxy resolutions. In most cases users will only need one resolution. This should be optional.

[I wish we could use the word "Import" instead of "Add". It is poor design that users need to Import stuff through an "Add" menu. File operations belongs in a File menu, but it's unrelated to this patch.]

There are no functional changes here technically, nothing is moved it's just more clearer representation of current possibilities.

These 3 patches should make it, such that user would not need to go to proxy settings panel. All should work out of the box. But he still can go there and do manual changes. Again we can hide this panel as was done with cache panel.

But the previews can use own proxy sizes then?

I think this may be error prone long term, but I think it's best approach right now.

I see your point. Lets put it this way. If the new code is more error-prone than the current situation I would advice against it. If it's less or same error-prone I'm fine with it.

Once we have means to cheaply downscale images from larger ones, this can be removed completely and there can be one global preview size.

One global "auto" review size, which you never need to change, yay! =)

In D10363#272117, @Sergey Sharybin (sergey) wrote:

But the previews can use own proxy sizes then?

Yes previews still can use own proxy size. If workspace is set up such that more proxy sizes are used, all these sizes are built at once so that user doesn't have to set these up manually.

I think this may be error prone long term, but I think it's best approach right now.

I see your point. Lets put it this way. If the new code is more error-prone than the current situation I would advice against it. If it's less or same error-prone I'm fine with it.

As written above, this is needed to ensure out of the box functionality.
I would trust this code personally. It's hard to compare it to current system, as there is no such feature currently. It can't fail in a way that would break functionality, worst case it could imact performance.

There is a bit more than trusting the code.

From a glance, the fact that adding strips is now needing some sort of synchronization of settings with the preview raises the following questions:

• What if there are one/none preview open?
• What if an artist manually modifies proxy settings in preview or in strip?

What I am trying to understand is that whether no matter what artists' actions and their order is the automatic part always gives an expected and predictable results.

In D10363#272123, @Sergey Sharybin (sergey) wrote:

There is a bit more than trusting the code.

From a glance, the fact that adding strips is now needing some sort of synchronization of settings with the preview raises the following questions:

• What if there are one/none preview open?
• What if an artist manually modifies proxy settings in preview or in strip?

Preview changes are handled in rna_space.c When new preview is created with different proxy size used or preview size is changed, proxies for this size are built on demand.
On demand building can be disabled in preferences, which is setting I would use normally.

What I am trying to understand is that whether no matter what artists' actions and their order is the automatic part always gives an expected and predictable results.

I think I understand your point, though I don't want to get stuck in "none or perfect" dichotomy. What would you suggest to do with this? I can only think to move sizes to be built by default to preferences, but this also isn't very good solution as some users would ask "what this even means in practice"?

I don't want to get stuck in "none or perfect" dichotomy

Sure, we shouldn't stuck just because something is not perfect. There is surely way to move forward here, don't worry ;)

What would you suggest to do with this?

Well, two non-exclusive things, I think.

If Francesco will be fine with it, we can consider this as a sufficient step forward, accepting it non-ideal aspects, and work on a more ideal world solution as a followup development.

For the more ideal world scenario, I think we need to remove proxy size settings from strip and gave preview the only place where they are configured. Kind of single source of truth thing.
Sounds straightforward, but I do see that it is not so trivial when it comes to an actual implementation.

So the plan I think should be:

• We check with Francesco the current state ASAP
• We then decide whether we go with this addition as it is
• We work on a more ideal world solution as a followup development from what we left with in the previous point

What do you think?

Btw, for the TODO you mentioned. I think building multiple sizes will suit best currently.

In D10363#272135, @Sergey Sharybin (sergey) wrote:

I don't want to get stuck in "none or perfect" dichotomy

Sure, we shouldn't stuck just because something is not perfect. There is surely way to move forward here, don't worry ;)

What would you suggest to do with this?

Well, two non-exclusive things, I think.

If Francesco will be fine with it, we can consider this as a sufficient step forward, accepting it non-ideal aspects, and work on a more ideal world solution as a followup development.

For the more ideal world scenario, I think we need to remove proxy size settings from strip and gave preview the only place where they are configured. Kind of single source of truth thing.
Sounds straightforward, but I do see that it is not so trivial when it comes to an actual implementation.

So the plan I think should be:

• We check with Francesco the current state ASAP
• We then decide whether we go with this addition as it is
• We work on a more ideal world solution as a followup development from what we left with in the previous point

What do you think?

Btw, for the TODO you mentioned. I think building multiple sizes will suit best currently.

Sounds good, I think that sinlge size approach is very much possible, only thing to think about is very large resolutions, there is considerable benefit of approximating all media sizes to chosem preview size. But that is talk for further development I would say.