When fractional scaling was used with libdecor the window decorations
would not match the window size on startup, drawing small and on top
of Blender's window.
While there are still glitches with fractional-scaling & libdecor
(which doesn't support fractional scaling),
see #109194 this at least resolves one of the worst issues.
When a new window is created the final buffer scale isn't known
so setting the buffer scale assuming the final state was just a guess
and only had the minor advantage of preventing rounding the window size
on startup.
Removing this to resolve a bug with LIBDECOR & fractional scaling
relating to #109194 (will commit separately).
Windows mouse warping bounds margin needs to be different when not
GHOST_kGrabHide, or else the visible wrapping occurs within the
area at an odd location. Making it 2, like it used to be.
The issue was caused by the custom code which was ensuring that closing
About window does not leave application without any key
windows.
Turns out that the windowWillClose is executed when menu is closed,
forcing the custom code to ensure a key window.
The solution is to only perform manual re-ordering if the closing window
was a key window. This both keeps old behavior of ensuring there is a
key window after closing About, and solves the ordering issues when a
window is created or activated via menus.
Pull Request: https://projects.blender.org/blender/blender/pulls/113515
The window contents and the window boarders were noticeably out of sync
when resizing the window quickly.
Resolve by keeping the current size as-is, rely on deferred handling
of the pending window size to apply the new size along with the contents.
Any window state change (resizing for e.g.) triggered
activation/deactivation events. Resolve by only sending events on state
change. The activation caused cursor motion events from #107594.
The problem was introduced in 636f3697ee
MacOS has a different way of handling the title.
In this OS the directory is searched and taken from the title string
which is then formatted.
This limits the title format and makes it prone to errors.
This commit makes the code more generic by splitting each component of
the title beforehand and allowing the associated directory to be informed
with `GHOST_SetTitle`.
There are secure implications of not using secure coding for the
restorable state described in the following article:
https://sector7.computest.nl/post/2022-08-process-injection-breaking-all-macos-security-layers-with-a-single-vulnerability/
Starting with macOS 14 this secure coding is enabled implicitly
but with a warning printed into the console with a note that it
does not affect other versions of macOS.
This change makes it so the secure coding is used explicitly on
all supported macOS versions.
Blender does not use the restorable state itself, and used its
own code to take care of window placement, so there should be
no user-measurable changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113240
It's possible for there to be no outputs under Wayland
(when unplugging monitors for e.g.) so this must be accounted for.
Also avoid calculating the window position when the GHOST backend
doesn't support window positions (which is the case for Wayland).
Add checks for the SDL backend too, where accessing the
screen & desktop size may fail.
Changes to the mouse cursor would only display when the main loop
was being handled, so blocking actions such as file load wouldn't
refresh the cursor.
Solve by flushing the display when the cursor changes.
Using SDL's initialization logic, this is mainly a change for XDG
as LIBDECOR already required a configure event before accessing
the underlying XDG window.
While I didn't notice functional changes with this change window
flickering on startup remains an issue with some compositors
(KDE & river). Debugging these issues is simpler when both windowing
decoration systems work in a similar way & window configuration
is guaranteed to have run before the window is returned.
(via #xdg_surface_ack_configure).
This PR enabled device features that are required for EEVEE-Next.
Enabling these features would allow an initial screen drawn by
EEVEE-Next.
Note:
* Changes to EEVEE-Next after this commit, might require other changes
* Not all features are working, but a basic diffuse cube without shadows
is.
* Vulkan views are not correct and leads to incorrect lighting.
Pull Request: https://projects.blender.org/blender/blender/pulls/112519
The check for control characters didn't account for delete (127).
This wasn't noticeable in most cases as delete is mapped to delete text.
Pressing Shift-Delete would enter 127 control character in the
text-editor, 3D text & Python console. This happened X11 & Wayland,
I didn't check other platforms.
Ghost uses vulkan in its public headers but none of the projects that
depend on ghost had the vulkan headers in its includes nor did
bf_intern_ghost expose this vulkan dependency itself publicly yet.
bf_windowmanager also did not express its dependency on
bf_intern_ghost yet used its headers.
this change fixes both issues.
Pull Request: https://projects.blender.org/blender/blender/pulls/112259
Shader draw parameter support is needed for Workbench-next. (Almost) All
devices that we support also supports shader draw parameters. This PR
doesn't include a workaround for devices that don't have support.
For end-users this PR will allow workbench-next to render the object on
the correct location. Before this patch they were always drawn on the origin.
The catch is that OpenGL uses gl_InstanceID which always starts counting at 0.
Vulkan has gl_InstanceIndex which holds the correct instance number. By
subtracting the gl_InstanceIndex from gl_BaseInstance will get the correct
gl_InstanceID.
This patch also activates some device extensions to perform in shader printf
statements inside a shader. Documentation for this will be added to the dev
docs how to use them.
Pull Request: https://projects.blender.org/blender/blender/pulls/111461
