Some operations may use no preferredResolution ({0, 0}) when calling determineResolution on inputs to check if they have resolution on their own. See MixOperation or MathOperation determineResolution implementation. In such cases {0, 0} resolution ends up being set when an input doesn't have own resolution, breaking propagation of the original preferredResolution. They don't mean to set it as resolution, it's just a check.

This patch only allows to set valid resolutions (>0). When it's 0 it may be understood as "No preferred or determined resolution" so it should not be set to give output operations another chance of finding a proper resolution by calling determineResolution again with a different preferredResolution.

Test file: