Regression from [0] based on the incorrect assumption that X11's
Time was a uint64. Despite the `Time` type being 8 bytes,
the value wraps at UINT32_MAX.
Details:
- GHOST_SystemX11::m_start_time now uses CLOCK_MONOTONIC instead of
gettimeofday(..) since event times should always increase.
- Event timestamps now accumulate uint32 rollover.
[0]: efef709ec73ce95817a82e4e26cf7ec0bad8eca0
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
The use-after-free is triggered when the GHOST system is created
multiple timers during the application timelife which happens in
the integration tests.
The solution is to release the application delegate and set it
to nil when the GHOST system is being destroyed. This ensures that
all subsequent GHOST systems properly initialize application
delegate, and that there is no application delegate which points
to a freed system.
The original issue was noticed by a flackey behavior of the
bf_gpu_tests test which was failing at random. The issue could
be reliably reproduced by running this test with ASAN enabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/116717
Using a non-null background brush does remove an initial white flash
while the program is loading and before we start painting. But this
results in some extra and unnecessary redraws. Default WM_ERASEBKGND
behaviour is to do nothing if this is brush is null, so if non-null we
get erased and must redraw. Suppressing WM_ERASEBKGND will not give us
that initial paint, so no benefit in keeping the brush added in #115968.
Pull Request: https://projects.blender.org/blender/blender/pulls/116642
There are some tragic design flaws with the Microsoft STL
implementation of `std::dequeue`. Unless we implement our
own similar data structure or use an implementation from
another library, the change isn't worth it.
This reverts commit b26cd6a4b9008836f9d764489b4aac5e143ad611.
This reverts commit cc11ba33d90e5a541e8263f7d365d6eeda9d984c.
This reverts commit c929d750541bc25131dec63c9c9e126a1370daf0.
This reverts commit bd3d5a750d2d0f5f72ed7ae262cd69abec4b0143.
GSQueue dates back over 21 years, past the initial git commit. Nowadays
we generally prefer to use data structures from the C++ standard library
or our own C++ data structures. Previous commits replaced this container
with `std::queue` in a few areas. Now it is unused and can be removed.
With the popularity of dark themes, and the fact that our default theme
is dark, make the initial background color (before the program fully
loads) a darker shade of grey. {0.25f, 0.25f, 0.25f} versus current
{0.55f, 0.55f, 0.55f}. Also set Windows class background brush to the
same color to remove a potential flash.
Pull Request: https://projects.blender.org/blender/blender/pulls/115968
Remove null IME checks for to resolve an assertion and allow for the
window be set at any time before the event has been generated,
or generate the events even when there is no window.
Reported by Lukas Toenne who ran into this while debugging.
Under GNOME resizing a window often caused the window contents could be
a different size to the window-frame, resizing was also slow.
This occurred with LIBDECOR on Wayland when a window configure event
was called from a non-main thread.
Resolve by postponing the commit-configuration call until the main event
can handle it (matching XDG behavior).
A workaround using malloc_usable_size is currently needed.
While relying on the malloc size is not so portable and worth avoiding,
it resolves noticeable glitches and allows other workarounds to be
removed.
Any application that supports threaded event handing with LIBDECOR
will need a way to postpone applying the configuration.
Even once LIBDECOR supports this properly, a workaround is necessary
until support older versions of LIBDECOR can be dropped.
This was an attempt to fix a crash resizing windows #107797
(which I can't reproduce), however it didn't fix the issue and meant
that a window would sometimes not reach the desired size,
the maximized window for e.g. would sometimes remain the un-maximized
size.
Since the preferred fractional scale callback runs,
remove a workaround that guessed the fractional scale from the output.
While it could be kept, it added unnecessary complexity.
Recent re-ordering change [0] on Wayland window initialization crashed
WLROOTS based compositors, resolve by keeping the updates and only
postponing the state change.
[0]: 39f378da37eedb918a69a31c68c34e5a9263754c
Starting blender with --window-maximized wouldn't always size the
windows properly, similar to the fix for LIBDECOR, move setting the
window state last.
With fractional scale under GNOME, the window frames didn't match
the window contents. This was caused by updates needed to call
libdecor_frame_get_xdg_toplevel initializing the LIBDECOR window
before the window scale, internal buffer - etc were set.
Resolve by accessing moving the window state assignment last.
When the final buffer scale is known, set the window scaling on startup.
This avoids scaling immediately after creating the window which
flickers. It also resolves an paper-cut with KDE where fractional
scaling caused the window to be placed on the screen center,
then the size increased pushing the window contents off the bottom right
hand portion of the screen.
From what I can tell time-stamps are supposed to be monotonic
however with LIBDECOR & GNOME click events after resizing the window
can cause this to happen.
Resolve by only considering the value wrapped when the new time-stamps
wrapped difference is less than the unwrapped difference.
Also skip wrapping when the current offset is closer to the current time
than it would be with the offset applied.
There were two problems here:
- libdecor_frame_get_content_* is not available in LIBDECOR v0.1.0.
- These functions aren't exposed by <libdecor.h>,
they're only exposed by `libdecor-plugin.h`
(intended for plug-ins that implement window decorations).
Resolve by storing the last applied size from LIBDECOR for reuse.
The previous fix for #106040 worked with GNOME, it relied on
matching GNOME's internal limits - which isn't fool proof
and could fail in the future.
Resolve by adding a `read` wrapper that reads the requested number of
bytes (when available).
