My current work-around is to keep my canvas at 1920x1080, but render out to 1280x720 for the moment until the bug is fixed. However, when I specify 1280x720 for the canvas Width and Height in the Render dialogue, it just straight crops the output to that size, rather than scale it to that size like I hoped.
Is there any way to do this? (Other than re-work the entire animation to downscale it, then re-work it again to upscale it when the bug is fixed!)
Yeah sorry guys. Now that I think about it, it worked previously, I forgot. And I tried it again and it worked as expected for some reason. But I’m looking at a file right now that represents my previous attempt, and it IS cropped. I just don’t know how it happened. Oh well, moving on. If I can reproduce it I’ll let you know.
Woah, really? That sucks… hahah. Well then, @KonstantinDmitriev, no I didn’t “accidentally” press it, I very “intentionally” pressed it, I just didn’t expect it to be buggy!
But, for some reason, when I change width/height manually from 480x270 to 1920x1080 - then it resizes.
And when I enable “lock ratio” and change width from 480 to 1920 (height automatically changes to 1080) - then it expands. This is a non-expected behavior.
The problem is that constraints on resize are set in the tab “Other”
The lock is acting only on the ratio of the physical dimensions of the image, to avoid to calculate and type the second dimension.
But the content is defined in logical dimensions (in Synfig Units of 60px).
According how the constraints are set, the result can be resize/crop of the content or even horizontal/vertical stretching.
But the constraints have to be set before any resize operation.
I can see that it works, once you understand how it works, so certainly this is not a bug - but a user interface design issue then? Of course this is a free project and maybe this doesn’t rate highly on the list of things to do, but if simply enabling a certain checkbox by default is the fix, that would solve the issue for pretty much 99% of use cases.