After dropping a selection via Copy (Selection + Ctrl), handles are not positioned correctly

[Gasparoken]

This is not new in 1.3rc5. The previous version 1.2.40 was fine in this regard.

Selection + Ctrl:
https://github.com/aseprite/aseprite/assets/32165475/49a5fad6-dbd4-4bda-ac93-24ed9b303ce4

Expected behavior similar to select move:
https://github.com/aseprite/aseprite/assets/32165475/a9d107b8-1ae6-48bd-ae8b-491700b5ec9c

Related: https://community.aseprite.org/t/selection-tool-ctrl-copy-shifts-selection-box-in-v1-3-seeking-solution/19518/1

Aseprite and System version

• Aseprite version: 1.3rc5
• System: macOS

[dacap]

This behavior was added explicitly in 3fbdd40 for fine control: (translation/scaling):

      <!-- When we are moving the selection, pressing this shortcut
           moves the selection to a subpixel level (floating point
           coordinates). Useful for anti-aliasing effects. -->
      <key action="FineControl" shortcut="Ctrl" context="TranslatingSelection" />
      <key action="FineControl" shortcut="Ctrl" context="ScalingSelection" />

Probably we can make it optional (disable by default) and enable it in a future when we add some kind of anti-alias transformation (although the fine control is still useful to create minimal variations in rotations/skew transformations).

[Gasparoken]

Ok, I've been thinking about how to improve this, what do you think?:

1. Locate de handlers in the corners of the selection when the artist release the mouse.
2. Perhaps, the image jumps would be better when the handlers cross the center of the pixel instead of the pixel boundaries. This way the handlers will be 1/2 pixel away from the expected non-fine position (current behavior: image jump occurs when the handlers cross a pixel boundary, so the handlers appear to always be offset 0 to 1 pixel to the right and down).

Anyway, we can add the switch to have both behaviors (but maybe not necessary by implementing at least '1').

[dacap]

I think we should try to avoid the confusing behavior which at the moment is the fine tuning of the selection position when we are just translating or making a copy of the selection with Ctrl+mouse drag (which is the specific problem reported in the forum).

There are a lot of things to fix in the selection transformation that we can leave for the future (#1847) but at the moment we could:

1. Disable the fine control when the transformation doesn't include rotation or skew (so just translating doesn't allow fine control until we rotate or skew, this might change in the future if we add a new anti-aliasing rotation algorithm)
2. The same as your 2) point, improve the position where/when the transformation jumps to the next pixel

A little video shows us how bad it's working right now the jump between pixels (when the marching ant effect disappears is when I start dragging), it looks like the dragging is one full pixel behind. The first half of the video is without fine control, and then after the skew transformation I think the fine control should be enabled with the Ctrl key:

Screencast.2023-07-25.10.47.37.mp4

[dacap]

Reimplemented to fix #4147, basically the fine control is enabled only if we release the Ctrl key and then we press it again after copying the selection (so fine control is only enabled when we press the Ctrl key while we are moving the selection and no when we start the movement which the copy of the selection is executed).