hi all,

here's a (totally unbiased ;-) summary from the previous "composition rendering" thread, intended as a discussion base:

1. Rendering happens on demand: a) when a composition gets displayed on screen (of course) b) on export. Here usually the full resolution gets rendered.

=> no rendering happens on saving. Only the necessary data gets written. Exceptions can be defined according to 3.)

2. A persistent disk cache of configurable size eliminates expensive re-calculations. (a cross-session cache is feasible with reasonable effort?!?)

Use case: Exporting an expensive composition for a second time should not cause re-rendering, unless the disk cache got overwritten in the meantime.

3. "Render Hint" operations can be inserted anywhere in a composition. These operations have only one option: "render full resolution when saving".

This way, the user can mark intermediate results from a composition for getting cached inside the saved composition file. These Render Hints have no effect during editing time.

Use case: Adding a "Render Hint" operation on top of the composition makes shure that a bitmap of the fully rendered composition gets included on saving.

Use case: A Render Hint after an expensive operation (e.g. denoise) protects the invested CPU time once the composition has been saved.

greetings, peter

hi,

peter sikking schrieb:

[..] the rest is technical detail and for actually contributing developers to figure out.

Of course, non-devs thinking about technical issues are at high risk of generating bogus discussion. On the other hand, the project has traditionally been open to thoughts from the outside.

if you just start with some unbreakable UI principles like:

when users save their file everything is stored on the disk; when

the question, what 'everything' consists of was my very starting point.

exporting a png, it is there at the end of the progress feedback; when an operation is made on a composition then it is done and users can see the result to take their next creative decision; when a file is huge then users' expectation of how long things take naturally scale accordingly.

then that is what users know and need to know and that is how it works as far they are concerned. the rest is technical detail and for actually contributing developers to figure out.

I have been pointing out ages ago that the screens users work on have only 1 or 2 or 3 million physical pixels and that is all that needs calculating asap, the rest can catch up in seconds. has an impact on how effortless zooming is, however...

OK, so there will be no user control for fine-tuning of saving/rendering. The cases, where the hard-coded strategy becomes inconvenient are considered corner cases not covered by the project vision.

Please correct me if i got it wrong.

greetings, peter