Bug 432036

SUMMARY

The Aspect ratio lock is ignored when trying to resize a cropped area beyond the image border. 

Note that the steps and results described below can be observed both in the horizontal and vertical domain - i.e. by interchanging both portrait/landscape and width/height in the steps below, the problem can be reproduced on either axis.

Video Demonstration:

https://fdpl.io/locked_ratio_crop_overflow.mp4 (<400kb, 28sec)

(Note: In the video also pay attention to the aspect ratio jumping around while resizing the cropped area *without* aspect ratio lock enabled - maybe symptomatic of why the problem happens *with* the lock, also UX wise feels a bit unclean that it jumps around, although functionally it poses no problem as it jumps back)


STEPS TO REPRODUCE

1. Have open a document with a portrait-type aspect ratio
2. Select the Crop Tool - make sure "Grow" is disabled
2. Begin a crop with a *locked landscape-type aspect ratio* (e.g. 1.9)
3. Resize the cropped area in width, going beyond the image border

OBSERVED RESULT

The height of the cropped area increases and increases, even when the cropped area already spans the full width (and thus does not expand anymore), therefore the locked aspect ratio is not maintained anymore at some point

EXPECTED RESULT

As soon as the cropped area spans the full width of the document it should not grow anymore, neither in width, nor in height - thereby the aspect ratio would be maintained, as the lock dictates.

SOFTWARE/OS VERSIONS

Observable in master as well as in latest released Krita (4.4.2)

ADDITIONAL INFORMATION

As far as I can see Dmitry has implemented an abstract rectangle class that handles these resizing constraints (width/height/aspect ratio), I haven't studied it in detail but I suspect the way it is implemented maybe doesn't cover this specific case documented here (yet) (hopefully the implementation model can cover it).

I might potentially look into a fix for this myself if available hands on the team are short for this, but either way I think it would be good if someone in the krita team first triages this, either laying out a preferred approach for a fix (if it needs larger changes) or maybe even fixing it right away if it happens to be a quick fix. :)