A windows pending actions wasn't cleared for new windows.
Although I'm not aware of user visible bugs, this prevents
unpredictable updates for new windows.
`shaderOutputLayer` and `shaderOutputViewportIndex` are optional in
Blender, but when used they should be activated on physical device level.
This wasn't the case and when used the validation layer reported an error.
This PR activates the features when creating the device if the features
are available.
Pull Request: https://projects.blender.org/blender/blender/pulls/114303
The last good commit was 8474716abb0db3b06838a57f7217bc945638d8df.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
While the fix worked in my tests, the compositor is allowed to ignore
a requested window state change which could have entered an eternal
loop. Avoid this by limiting the while loop to 2x round-trips.
Even though the window was maximized, the non-maximized size was used.
Since the display size was used the window would be slightly larger,
clipping the status bar in GNOME.
As the window state will have been initialized, read the current window
state instead of assuming normal so changes are properly detected.
Also note that the cause of #107314 has been fixed up-stream.
When the output wasn't fractionally scaled but the compositor supports
fractional scaling, new windows were smaller than requested.
Caused by [0] which was incorrectly calculating the non-fractional scale
used by LIBDECOR (which isn't accessible via it's API).
Resolve by only using fractional scaling logic when outputs
have a fractional component.
[0]: 3eda5a114f14d14e1a454d97c9e5496247fe6c21
Tested with IBUS on GNOME 45.
Added a capabilities flag to GHOST since support for IME works on
Wayland but not on X11, so runtime detection is needed.
The USE_LIBDECOR_FRACTIONAL_SCALE_HACK worked on my system but made
window size issues worse in older versions of GNOME, see: #109194.
Replace the hack with logic to set the window size using frational
scaling information from the output.
When fractional scaling is used, window sizes from LIBDECOR are still
divided by the window-decorations internal buffer scale which doesn't
match the GHOST window (always 1 in the case of fractional scale).
Also resolve glitches caused by recalculating the window size when
no size change was intended. In this case reuse LIBDECOR's internal
size so there are never any changes (caused by rounding for e.g.).
When the window manager set the window size, there were no checks
the size is a multiple of the buffer scale (a requirement for Wayland).
This meant setting the window size could exit Blender without warning
if an invalid window size was set.
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).
When running Blender inside renderdoc an extension can be used to print
from any shader stage to the console. This is useful during developing,
but not so during running/triaging. For now we remove the extension to
not confuse by incorrect error messages.
Pull Request: https://projects.blender.org/blender/blender/pulls/113654
This PR adds workarounds for platforms that don't support `shaderOutputLayer`
or `shaderOutputViewportIndex`. Some NVIDIA laptop GPUs and ARM GPUs don't
have those device features.
The workaround uses the same approach as OpenGL. A geometry shader is injected
to emulate the feature.
For testing the workarounds they have also been connected to the
`--debug-gpu-force-workarounds` command line argument.
Fixes#113475 by implementing #113529
Pull Request: https://projects.blender.org/blender/blender/pulls/113605
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
In some cases processing events was modifying them, as there can be
multiple event consumers, manipulating events isn't correct.
Even though in practice it didn't cause issues, it's straightforward
not to do this and makes logic easier to reason about.
IME editing would cast GHOST_TEventImeData to wmIMEData then read/write
an additional member that doesn't exist in GHOST_TEventImeData.
In practice it's likely struct padding prevented this from showing up
as a bug. Nevertheless it's bad practice to rely on this.
- Make GHOST_TEventImeData read-only, move the is_ime_composing boolean
into the window.
- Add static assert to ensure both structs are the same size.
- Correct code comments.
This was only used for accessing cursor themes which only worked
with gnome and wasn't used in official releases.
Use the default theme or the theme defined by XCURSOR_THEME.
Eventually wp_cursor_shape_manager_v1 can be supported which avoids
having to access the theme.
Wayland WSI would crash the system when used. The reason is that the
wayland vulkan WSI doesn't provide windowing support. Vulkan gets full access
to the desktop of the OS and it is the responsibilty of the application to
do the right thing.
For OpenGL Wayland proved basic windowing support using `wayland-egl.h`.
Which essentially is a tiny wrapper that keeps track of the window position and
size.
This PR changes a few things to make the Wayland surface usable:
- Do not load debug extensions when blender isn't started with
`--debug-gpu`.
- Recreate swapchain images when surface size changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/113007
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.
`VK_KHR_maintenance4` extension is core in Vulkan 1.3. As Blender
should support Vulkan 1.2 we should not enable this extension when
it isn't available.This fixes issue to run Vulkan backend on some
platforms (Intel Iris Plus).
Maintenance4 is used to relax the interface matching rules to allow
a larger output vector to match with a smaller input vector, with
additional values being discarded.
When Maintenance4 isn't enabled a few shaders might run a tiny bit
slower as it triggers a performance notice. Users won't notice the
performance slowdown.
Pull Request: https://projects.blender.org/blender/blender/pulls/113239
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`.
Pull Request: https://projects.blender.org/blender/blender/pulls/113227
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
Problem caused by [0], resolve by only printing error messages
when none of the GHOST back-ends are able to start.
[0]: f58d596c36c81245ed8c5723e5fa8369106a7a80
This is a rewrite of GHOST_ContextVK to align with Metal backend as described
in #111389 - solution 3 with the adaptation that GHOST is still responsible
for presenting the swap chain image and a post callback is still needed in
case the swapchain is recreated.
This PR also includes some smaller improvements in stability.
Technical documentation: https://developer.blender.org/docs/eevee_and_viewport/gpu/vulkan/swap_chain/
* Renderpasses and framebuffers are not owned anymore by GHOST_ContextVK
* VKFramebuffer doesn't contain a swap chain image.
* Swapchain images can only be used as a blit destination or present source.
Not as an attachment.
* GHOST_ContextVK::swapBuffers would call a callback with the image the
GPU module needs to blit the results to.
* Clearing of depth/stencil attachments when no depth write state is set.
* Enable VK_KHR_maintenance4 to relax the stage interface mapping.
* Removes most vulkan validation warnings/errors.
* Detection of frame buffer changes that needs to be applied before
performing a command requiring render pass (draw/clear attachment)
**Benefits**
* Late retrieval of a swap chain image results in better overall performance as
Blender doesn't need to wait until the image is presented on the screen.
* Easier API and clearer state (transitions)
* More control over Image layouts and command buffer states. (Better alignment with
Vulkan API)
Pull Request: https://projects.blender.org/blender/blender/pulls/111473
Implements the GHOST_GetPixelAtCursor for the X11 backend, allowing
the user to sample any color displayed on the screen.
Noted some limitations in the code-comments.
Ref !111493.
- GHOST_SystemPathsCocoa::getUserSpecialDir
used `strncpy` without ensuring the string was null terminated.
- GHOST_SystemPathsCocoa::getBinaryDir
used `strcpy` without checking the destination buffer size.
The recent change to header copyrights [0] unintentionally changed
"Blender Foundation" to "Blender Authors" for the WIN32 file path
which blender is installed into.
Revert lines changed that aren't related to copyright text.
[0]: e955c94ed38595cb12fa6cf517b6ba8033017141
This adds a new Ghost function, GHOST_GetPixelAtCursor, that allows
picking colors from outside of Blender windows. This only has an
implementation for the Windows platform, but this should allow other
platforms to also do so if possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/105324
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
With the introduction of metal and vulkan we use a different
GPU backend selection which broke the dialog box for unsupported
platforms.
Blender asserted and segfaulted before the dialog was being shown
to the user.
This patch solves this by introducing a dummy GPU backend in case no
GPU backend was supported by OpenGL, Metal and Vulkan Backend.
It also adds the showMessageBox to GHOST_SystemCocoa.
Related to #110335
Pull Request: https://projects.blender.org/blender/blender/pulls/110919
Add a High Dynamic Range option in the Color Management > Display panel.
This enables display of extended color ranges above 1.0 for the 3D
viewport, image editor and render previews.
This requires a monitor that can display HDR colors, and a view
transform designed for HDR output. The Standard view transform works,
but Filmic does not as it was designed to bring values into the 0..1
range for SDR displays.
This patch is limited to allowing the display to visualize extended
colors, but does not include future looking work to better integrate HDR
into the full workflow.
It is implemented by rendering to high bit-depth texture formats for
the user interface, and uncapping the color range in color management.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/105662
This add the possibility to define different
viewports inside a single framebuffer and
let the vertex shader decide which viewport
to render to.
This only contain the GL and VK implementation.
The Vulkan implementation works but still
has a validation error related to shader features
and extension. The test passes nonetheless.
Pull Request: https://projects.blender.org/blender/blender/pulls/110923
