This fix solves u,v set calculation when 'image brush' are used.
The cause of this bug is that we considered the set m_u, m_v as constants.
We have several cases when we are working on X axis:
- Scanline entirely contained in a tile, but OUTSIDE of the reference tile.
- Scanline entirely contained in a tile, but INSIDE of the reference tile.
- The left side of a scanline which was sliced (by the tile limit).
- The right side of a scanline which was sliced (by the tile limit).
Each one has its own m_u, so we need to recalculate it before every loop->getInk()->inkHline(...).
We have to take similar considerations when we are working in the Y axis.
We need recalculate m_v according if 'y+scanline.y' is INSIDE or OUTSIDE of the reference tile, each case has its own m_v.
Bug reports:
* https://community.aseprite.org/t/1183
* https://community.aseprite.org/t/4695
Here we avoid two ExpandCelCanvas at the same time with
MovingPixelsState + DrawingState. Double-clicking inside the selection
when we are moving it (MovingPixelsState) could start a new
DrawingState which creates a new ToolLoopImpl that needs a new
ExpandCelCanvas. So we have to drop the pixels before.
If we use two sprites with different canvas sizes, and both sprites
have a similar cel, they can share the inTextureBounds, but not the
original size (which is the original sprite canvas size of each cel).
This can be reproduced using the CLI and creating a texture
atlas (-sheet) with two or more sprites.
This can happen when we use -trim (Trim Cels) + -merge-duplicates
options together. The trimmed bounds are unique to each sample, and
only the position in the texture (inTextureBounds) can be shared.
Fixes: https://igarastudio.zendesk.com/agent/tickets/407
When the backup thread is running, the upgradeToWrite() needed some
extra time to lock the document to check if we can write or not in the
sprite. Now we just check the ability to write the sprite with the new
RWLock::canWriteLockFromRead() function.
The mouse position jumps from one side to other when we zoom because
there were an intermediate scroll change event where the mouse
position is converted using the old zoom.
Fixed regressiong from 951fb7c35784d3e5b0aba86e340aed9edbd2456d
Fixed bug https://community.aseprite.org/t/4587
Use the app::Color alpha property to create the color for an
image (app::color_utils::color_for_image()) in several cases.
Fixed https://community.aseprite.org/t/4548
Now we store the callbacks in a table that depends of the lifetime of
the dialog (instead of the global registry), so when the dialog is not
used anymore/closed, the whole "island" of objects (dialog +
callbacks) is GC'd.
With this change we fix some tests when !ENABLE_UI and we start using
less Preferences::instance() (maybe in the future we could exclusively
access the preferences from the new Context::preferences() function).
