Made Change Color: Increment/Decrement Foreground/Background methods cyclic instead of clamped. At last palette element, incrementing selected color returns to first element. At first palette element, decrementing color returns to last element.
Before this fix, it was possible to lose the transparent index at Indexed Color Mode.
It was reproducible doing:
- New file, Indexed mode, Black background.
- Erase all the palette, add 40 colors slots (these all will be black)
- Press Remap button
- Go to Sprite > Properties... set transparent color to 11.
- Erase color entries 2 to 20
- Press Remap button
You'll see the transparent index is gone (transparent index = -1)
To reproduce the crash, additional steps are needed:
- Right click to layer and select 'Layer from Background'
- Make a color RGBA(0, 0, 0, 0) and add to the palette
- Paint on canvas with this color (it'll act like a eraser)
- File > Save As... save in GIF format.
- Press OK
Crash!
This crash was reported on ticket 2620 and 2621.
Removes switch case with fall through. Removes nested switch
cases. Refactors color sorting method to 1. push zero alpha colors to
the front of the palette; 2. resort to value as a criterion for gray
colors; 3. use saturation and value as back up comparisons for each
other for equivalent values; 4. approximate gamma-to-linear when
perceptual lightness is chosen.
Partial fix for #2901.
Maybe it's not the final version, but it's a good start. We cannot
match the coding style that we were using, but it's pretty close.
We'll start applying clang-format incrementally in a near future.
ase_file_write_start_chunk needs to skip forward the size of the chunk header, as these values will be written in later. Using fseek was causing performance issues on my Windows machine due to causing an io flush on every chunk, for projects with many (thousands) of chunks. Replacing with the equivalent put commands in ase_file_write_close_chunk results in ~100x speedup.
This should improve the mouse movement, where a new mouse cursor was
created on each mouse movement with black & white pixels. It's a
regression introduced in ef4f691459
(which was originally introduced to improve the mouse movement
perception in a 100Hz monitor).
This might be a possible fix for:
https://github.com/aseprite/aseprite/issues/2713
Some features from the beta branch of aseprite & laf were backported
to the main branch of aseprite.
Related commits:
- New memory handling (db4504e816)
- New get event with timeout (e6ec13cc31)
- Convert os::NativeCursor to an enum (06a5b4f3ae)
- Adapt code to the new os::Display -> os::Window refactor (5d31314cdb)
- Save/load main window layout correctly and limit to current workarea (d6acb9e20f)
- Redraw window immediately on "live resizing" (d0b39ebade)
The original intention was to save selected colors in the Replace
Color dialog so then showing up it again would restore those saved
color. But it never worked in that way and just by mistake it was
using the Foreground/Background pair of colors by default (which is
the desidered behavior now). So we are just removing the buggy code
that never worked. (Related to #2028 in some way.)
