Regression in dd0c296209 (Use
tooltip_text style & color to paint tooltip windows #2554).
Prior this fix, text box does not update its bounds area because it
has not a style assigned.
Fix#3442, fix#3443
It looks like processing a specific kPaintMessage with
ui::Widget::sendMessage() might re-create the os::Surface and destroy
the previous one, so we need to keep a reference to the previous
surface just in case to keep it alive.
We aren't able to reproduce this crash, but we've received several
Sentry reports about it, only on Windows and since v1.2.34.1 (not sure
if it's related to that). We'll see if this does fix the crashes or we
have some kind of regression in the future.
Can happen when a resize event is received and m_captured stores the
surface with the old window size.
This was found opening a file from the CLI on Linux/X11.
Also we've restored the default algorithm to bilinear + mipmapping,
which was the default on the Aseprite before we switched to Skia m96.
This was requested by some users.
Mainly for Line-like tools (which require the last mouse position
only). Related to #3119, possible fix for several performance issues
on Linux mainly.
Incomplete version of the Lua debugger.
Some available features:
* Break in next executed instruction
* Step in, over, out
* See & navigate stacktrace
* See local variables
Some missing features:
* Breakpoints
* Eval user expressions with local variables
The UX needs some improvement yet.
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)
We weren't able to reproduce the crash, but these checks will prevent
the crash itself. (So in the future if we receive a related report, it
will be because something is not working correctly in the menus, but
not a crash report.)