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]: 39f378da37
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).
When creating Blender events in Win32 message processing we are using
the current time as timestamp. This isn't set until we collect them, so
this might be inaccurate at times of high load. This PR changes to using
the time the message was delivered.
Pull Request: https://projects.blender.org/blender/blender/pulls/115872
Due to changes in the build environment shader_builder wasn't able to
compile on macOs. This patch reverts several recent changes to CMake files.
* dbb2844ed9
* 94817f64b9
* 1b6cd937ff
The idea is that in the near future shader_builder will run on the buildbot as
part of any regular build to ensure that changes to the CMake doesn't break
shader_builder and we only detect it after a few days.
Pull Request: https://projects.blender.org/blender/blender/pulls/115929
Themes that didn't define "color-picker" showed the default cursor.
Resolve by checking if the theme contains a cursor,
not just that the name is known.
When the result of getMilliSeconds & wayland time-stamps match,
bypass more involved logic which attempts to maintain a delta and
return the time-stamp with an offset (to account for 32bit rollover).
NDEBUG is part of the C standard and disables asserts. Only this will
now be used to decide if asserts are enabled.
DEBUG was a Blender specific define, that has now been removed.
_DEBUG is a Visual Studio define for builds in Debug configuration.
Blender defines this for all platforms. This is still used in a few
places in the draw code, and in external libraries Bullet and Mantaflow.
Pull Request: https://projects.blender.org/blender/blender/pulls/115774