Without this fix windows were missing a last re-layout/setBounds to
the new frame size, so they showed up with an incorrect size given the
available area of the native window.
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.
Before this fix, when some aseprite file with transparents pixels was
converted to GIF, each frame didn't overwrite correctly the previous
frame (image disposal was incorretly chosen: DO_NOT_DISPOSE instead of
RESTORE_BGCOLOR).
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.)
