Sander de Regt wrote:Since you're starting to throw around technical terms now, it's clear that I am out of my depth in discussing this. I'm going to step away from this part of the conversation now, since you obviously know more about this stuff than I do.
It’s off topic but maybe of interest so I’ll explain a bit about what I mean. Each frame is produced from a limited set of parameters. These include the current context (view, proxy setting etc), all knob values which change the node result, and node inputs. All these can be compounded together to create a value (hash) that describes this unique combination. The hash of node is used as part of hash of every node which has it connected as input. This cascading hashing uniquely defines a render result without need to render. Each cached frame should include the hash of last node and check for whether frame exists in cache is done by checking the hashes. If they match, result is also the same (if it doesn’t work, some changing params are not properly accounted for or system is not deterministic). Expressions are evaluated to their final values before render and these final values are what get hashed together. So if expression evaluates to same result, rendered frame also matches.
For loaders, match is in part determined by file path. This is also the reason why for read inputs cache must be explicitly invalidated when file is overwritten with new content unless there is a check into file metadata, like modification time etc. Matching the actual content isn’t feasible because that would mean duplicating the whole frame somewhere and doing a time-consuming pixel by pixel matching test which is a lot slower than just reading it again.