blender
/
blender
133
398
Fork 579
Code Issues 6.2k Pull Requests 744 Projects 19 Wiki Activity

Image Access in Compositor Backdrop is not thread-safe #118337

New Issue
Open
opened 2024-02-15 17:14:02 +01:00 by michael campbell · 11 comments
michael campbell commented 2024-02-15 17:14:02 +01:00
Copy Link

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.58

Blender Version
Broken: version: 4.2.0 Alpha, branch: main, commit date: 2024-02-13 07:22, hash: 9ad127780af9
Worked: (in tiled mode)

Short description of error
Full frame compositor backdrop disappears during playback due to performance issue not present in tiled or GPU execution modes

Exact steps for others to reproduce the error

  1. download below blend file and open with load ui enabled.
  2. making sure no other addons are installed that have frame change handlers,
  3. go to the script editor and run the script
  4. use one of the arrow keys to change to a frame between 1 and 10
  5. in the compositor, ensuring the backdrop is on, try playback in Tiled, Full Frame, and GPU compositors (you'll need to enable experimental compositor in the Blender preferences for those options to appear in the compositor n panel options tab)

Blend file link: https://www.dropbox.com/scl/fi/uqt6ghyw6aw16j32ospvz/full-frame-mode-image-update-performance-issue.zip?rlkey=3urj9sbde7pesmpupg5dk0bzm&dl=0

For me the backdrop in Tiled mode is buttery smooth, GPU is strangely very slow, and Full frame is so slow that it can't display anything before the playhead moves to the next frame.

If I call render.render() after updating the image filepath, this will force the compositor to wait until the tree finishes processing before moving to the next frame. Strangely Full Frame mode is the fastest in this case, which suggests the issue isn't full frame being slower, but perhaps it not interacting with the backdrop as quickly? If you try this you'll need to avoid recursion by setting a variable preventing the handler to execute multiple times per frame, because the frame change handler also fires after rendering.

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 537.58 **Blender Version** Broken: version: 4.2.0 Alpha, branch: main, commit date: 2024-02-13 07:22, hash: `9ad127780af9` Worked: (in tiled mode) **Short description of error** Full frame compositor backdrop disappears during playback due to performance issue not present in tiled or GPU execution modes **Exact steps for others to reproduce the error** 1. download below blend file and open with load ui enabled. 2. making sure no other addons are installed that have frame change handlers, 3. go to the script editor and run the script 4. use one of the arrow keys to change to a frame between 1 and 10 5. in the compositor, ensuring the backdrop is on, try playback in Tiled, Full Frame, and GPU compositors (you'll need to enable experimental compositor in the Blender preferences for those options to appear in the compositor n panel options tab) Blend file link: https://www.dropbox.com/scl/fi/uqt6ghyw6aw16j32ospvz/full-frame-mode-image-update-performance-issue.zip?rlkey=3urj9sbde7pesmpupg5dk0bzm&dl=0 For me the backdrop in Tiled mode is buttery smooth, GPU is strangely very slow, and Full frame is so slow that it can't display anything before the playhead moves to the next frame. If I call render.render() after updating the image filepath, this will force the compositor to wait until the tree finishes processing before moving to the next frame. Strangely Full Frame mode is the fastest in this case, which suggests the issue isn't full frame being slower, but perhaps it not interacting with the backdrop as quickly? If you try this you'll need to avoid recursion by setting a variable preventing the handler to execute multiple times per frame, because the frame change handler also fires after rendering.
michael campbell added the
Priority
Normal
Type
Report
Status
Needs Triage
 labels 2024-02-15 17:14:02 +01:00
Iliya Katushenock added the
Interest
Compositing
Interest
VFX & Video
 labels 2024-02-15 17:30:10 +01:00
Germano Cavalcante commented 2024-02-15 20:27:10 +01:00
Member
Copy Link

When trying to replicate the problem in the latest daily build, I found that neither Tiled nor Full Frame options are available. It appears that these modes were removed in a previous commit (a8a05ebba1). I'm not sure yet why this change was made (cc @Sergey).

Regarding the issue you described, it seems that the backdrop not being able to compute the composition at the same time as the playback may not be considered a bug. The backdrop is not intended to be used for video playback.

If your intention is to request an improvement in performance, I'm afraid that potential performance improvements are not handled as bug reports. However, you can be assured that the developers are continuously working on improving performance in general.

Did I misunderstand the issue?

When trying to replicate the problem in the [latest daily build](https://builder.blender.org/download/), I found that neither Tiled nor Full Frame options are available. It appears that these modes were removed in a previous commit (a8a05ebba170abf3047d83a610eaf6198d26a025). I'm not sure yet why this change was made (cc @Sergey). Regarding the issue you described, it seems that the backdrop not being able to compute the composition at the same time as the playback may not be considered a bug. The backdrop is not intended to be used for video playback. If your intention is to request an improvement in performance, I'm afraid that potential performance improvements are not handled as bug reports. However, you can be assured that the developers are continuously working on improving performance in general. Did I misunderstand the issue?
Germano Cavalcante added
Status
Needs Information from User
 and removed
Status
Needs Triage
 labels 2024-02-15 20:27:20 +01:00
michael campbell commented 2024-02-15 20:44:43 +01:00
Author
Copy Link

The tiled was removed on Monday, so you'll need to compare your build with a pre-monday build.

It affects addons with caching systems.

I think maybe it's a bug because it works in the old tiled mode and current GPU mode without issue. I don't think it's a performance improvement issue because the full frame is actually faster than tiled mode to process the tree.

The tiled was removed on Monday, so you'll need to compare your build with a pre-monday build. It affects addons with caching systems. I think maybe it's a bug because it works in the old tiled mode and current GPU mode without issue. I don't think it's a performance improvement issue because the full frame is actually faster than tiled mode to process the tree.
michael campbell commented 2024-02-15 20:45:29 +01:00
Author
Copy Link

oh sorry, I clicked the wrong button.

oh sorry, I clicked the wrong button.
Blender Bot added
Status
Archived
 and removed
Status
Needs Information from User
 labels 2024-02-15 20:45:54 +01:00
Iliya Katushenock added
Status
Needs Information from User
 and removed
Status
Archived
 labels 2024-02-15 20:58:17 +01:00
michael campbell commented 2024-02-15 21:01:58 +01:00
Author
Copy Link

forgot to mention, it also affects the image editor.

forgot to mention, it also affects the image editor.
Sergey Sharybin commented 2024-02-16 10:50:43 +01:00
Owner
Copy Link

@mano-wii This was done as part of #106533, https://devtalk.blender.org/t/improved-render-compositor-feedback-and-discussion/33377

Compositor is not really meant to be executed during playback, as it will not be able to keep up with the frame-rate. This is how regular animation is handling it: if you have animated property playback does not trigger compositing. Updating image path forces compositor to refresh, but it is more of a side-effect when is done from a frame-update handler. However, ideally I think would be if the preview image is not cleared when compositing is cancelled.

I gave it a dig in the code, and it seems that the MultilayerBaseOperation::get_im_buf is not thread-safe: it does if (BKE_image_multilayer_index()) { /* acquire ibuf */ }. The BKE_image_multilayer_index is not thread-safe, so if the image path is changed from a different thread it the call might access stale or null-ified image_->rr. Or, the path might be changed in-between of the index check and ibuf acquisition.

I am not sure why do we even need the explicit check BKE_image_multilayer_index prior to the ibuf acquisition. It is safer to always call get_im_buf, which will do thread-safe ibuf acquisition. There is still unsafe call to BKE_image_is_multilayer in the get_im_buf, which potentially might leads to issues if frame update handler changes image type, but that's a separate story from this report.

@OmarEmaraDev Would be nice to have a second pair of eyes. Do you see anything potential issues if we do

ImBuf *MultilayerBaseOperation::get_im_buf()
{
  /* temporarily changes the view to get the right ImBuf */
  const int view = image_user_->view;

  image_user_->view = view_;
  image_user_->pass = pass_id_;

  ImBuf *ibuf = BaseImageOperation::get_im_buf();
  image_user_->view = view;
  return ibuf;
}

?

@mano-wii This was done as part of #106533, https://devtalk.blender.org/t/improved-render-compositor-feedback-and-discussion/33377 Compositor is not really meant to be executed during playback, as it will not be able to keep up with the frame-rate. This is how regular animation is handling it: if you have animated property playback does not trigger compositing. Updating image path forces compositor to refresh, but it is more of a side-effect when is done from a frame-update handler. However, ideally I think would be if the preview image is not cleared when compositing is cancelled. I gave it a dig in the code, and it seems that the `MultilayerBaseOperation::get_im_buf` is not thread-safe: it does `if (BKE_image_multilayer_index()) { /* acquire ibuf */ }`. The `BKE_image_multilayer_index` is not thread-safe, so if the image path is changed from a different thread it the call might access stale or null-ified `image_->rr`. Or, the path might be changed in-between of the index check and ibuf acquisition. I am not sure why do we even need the explicit check `BKE_image_multilayer_index` prior to the `ibuf` acquisition. It is safer to always call `get_im_buf`, which will do thread-safe `ibuf` acquisition. There is still unsafe call to `BKE_image_is_multilayer` in the `get_im_buf`, which potentially might leads to issues if frame update handler changes image type, but that's a separate story from this report. @OmarEmaraDev Would be nice to have a second pair of eyes. Do you see anything potential issues if we do ``` ImBuf *MultilayerBaseOperation::get_im_buf() { /* temporarily changes the view to get the right ImBuf */ const int view = image_user_->view; image_user_->view = view_; image_user_->pass = pass_id_; ImBuf *ibuf = BaseImageOperation::get_im_buf(); image_user_->view = view; return ibuf; } ``` ?
Omar Emara commented 2024-02-16 11:18:20 +01:00
Member
Copy Link

@Sergey I will check myself. But immediately, just to clarify, BKE_image_multilayer_index setup the multi_index in the image user, which is necessary as far as I can remember. So removing it might not side-effect free. But maybe I don't remember exactly, so I will take another look.

@Sergey I will check myself. But immediately, just to clarify, `BKE_image_multilayer_index` setup the `multi_index` in the image user, which is necessary as far as I can remember. So removing it might not side-effect free. But maybe I don't remember exactly, so I will take another look.
Omar Emara commented 2024-02-16 12:17:07 +01:00
Member
Copy Link

@Sergey I took another look, and I don't think we can remove that function call, since it initialized the multi_index necessary to acquire the buffer.

@Sergey I took another look, and I don't think we can remove that function call, since it initialized the `multi_index` necessary to acquire the buffer.
Sergey Sharybin commented 2024-02-16 12:26:04 +01:00
Owner
Copy Link

@OmarEmaraDev Ah, it looked like the get_im_buf sets the multi_index, but it only does it for non-multilayer images.
Ok, so we need to find a different way ensuring thread-safety of image access.

@OmarEmaraDev Ah, it looked like the `get_im_buf` sets the `multi_index`, but it only does it for non-multilayer images. Ok, so we need to find a different way ensuring thread-safety of image access.
Germano Cavalcante changed title from Full frame compositor backdrop disappears during playback. Issue not present in tiled or GPU execution modes to Image Access in Compositor Backdrop is not thread-safe 2024-02-27 14:12:12 +01:00
michael campbell commented 2024-03-04 19:58:24 +01:00
Author
Copy Link

@Sergey could this issue also cause the below error when trying to write to the image datablock after rendering completes?

bpy.data.scenes[scene_name].node_tree.nodes[cache_node_name].image.filepath = new_exr_path

Error:

 'AttributeError: Writing to ID classes in this context is not allowed: cache for Scene-Camera-ViewLayer, Image datablock, error setting Image.filepath\n']

Before attempting to update the image datablock's filepath, I'm ensuring the compositor and render have fully finished, and I'm launching the function from queue.queue() to make sure it's back on the main thread. I'm not sure why it's saying can't write in this context:

#runs from queue.queue() after rendering completes

if bpy.app.version >= (3,3,0):
        if bpy.app.is_job_running('RENDER'):
            #print('render has still not completed')
            return 0.0001
        if bpy.app.is_job_running('COMPOSITE'):
            #print('compositing in progress')
            return 0.0001
bpy.data.scenes[scene_name].node_tree.nodes[cache_node_name].image.filepath = new_exr_path
@Sergey could this issue also cause the below error when trying to write to the image datablock after rendering completes? ```bpy.data.scenes[scene_name].node_tree.nodes[cache_node_name].image.filepath = new_exr_path``` Error: ``` 'AttributeError: Writing to ID classes in this context is not allowed: cache for Scene-Camera-ViewLayer, Image datablock, error setting Image.filepath\n'] ``` Before attempting to update the image datablock's filepath, I'm ensuring the compositor and render have fully finished, and I'm launching the function from queue.queue() to make sure it's back on the main thread. I'm not sure why it's saying can't write in this context: ``` #runs from queue.queue() after rendering completes if bpy.app.version >= (3,3,0): if bpy.app.is_job_running('RENDER'): #print('render has still not completed') return 0.0001 if bpy.app.is_job_running('COMPOSITE'): #print('compositing in progress') return 0.0001 bpy.data.scenes[scene_name].node_tree.nodes[cache_node_name].image.filepath = new_exr_path ```
Sergey Sharybin commented 2024-03-05 10:31:46 +01:00
Owner
Copy Link

@3di It looks to me a separate issue. It might be that you're modifying an image from a non-main thread, while main thread is in a state where modification of IDs is not allowed. I don't fully understand this check for whether ID is allowed to be modified or not, and it probably worth submitting a separate issue about it. It might or might not leat to the same root issue, but it needs a separate investigation.

It would also be nice if you try to reproduce the AttributeError with Compositor disabled in the Post-processing settings.

@3di It looks to me a separate issue. It might be that you're modifying an image from a non-main thread, while main thread is in a state where modification of IDs is not allowed. I don't fully understand this check for whether ID is allowed to be modified or not, and it probably worth submitting a separate issue about it. It might or might not leat to the same root issue, but it needs a separate investigation. It would also be nice if you try to reproduce the `AttributeError` with Compositor disabled in the Post-processing settings.
michael campbell commented 2024-03-05 18:51:25 +01:00
Author
Copy Link

@Sergey thanks. I did create this report a while back #114455 (comment) , but at that time I thought it was because is_job_running was returning the incorrect result.

The python code doesn't run until back in the main thread, because it's executed from queue.queue() which doesn't run until back in the main thread as I understand it. Perhaps Blender is incorrectly raising the error because it thinks it's not back in the main thread when it is?

It must be a difficult one to solve, because even jacques lucke couldn't fix it when he ran into the problem several years ago with his animation nodes addon.

@Sergey thanks. I did create this report a while back https://projects.blender.org/blender/blender/issues/114455#issuecomment-1119612 , but at that time I thought it was because ```is_job_running``` was returning the incorrect result. The python code doesn't run until back in the main thread, because it's executed from queue.queue() which doesn't run until back in the main thread as I understand it. Perhaps Blender is incorrectly raising the error because it thinks it's not back in the main thread when it is? It must be a difficult one to solve, because even jacques lucke couldn't fix it when he ran into the problem several years ago with his animation nodes addon.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
brush-assets-project
universal-scene-description
fix-121021
blender-v4.1-release
blender-v3.3-release
blender-v3.6-release
blender-v3.6-temp_wmoss_animrig_public
temp-sculpt-dyntopo
gpencil-next
anim/animation-id-113594
blender-v4.0-release
blender-projects-basics
bridge-curves
sculpt-blender
asset-browser-frontend-split
asset-shelf
tmp-usd-python-mtl
tmp-usd-3.6
blender-v3.5-release
blender-v2.93-release
realtime-clock
sculpt-dev
bevelv2
xr-dev
v4.1.1
v3.6.11
v3.3.18
v4.1.0
v3.3.17
v3.6.10
v3.6.9
v3.3.16
v3.6.8
v3.6.7
v3.3.14
v4.0.2
v4.0.1
v4.0.0
v3.6.5
v3.3.12
v3.6.4
v3.6.3
v3.3.11
v3.6.2
v3.3.10
v3.6.1
v3.3.9
v3.6.0
v3.3.8
v3.3.7
v2.93.18
v3.5.1
v3.3.6
v2.93.17
v3.5.0
v2.93.16
v3.3.5
v3.3.4
v2.93.15
v2.93.14
v3.3.3
v2.93.13
v2.93.12
v3.4.1
v3.3.2
v3.4.0
v3.3.1
v2.93.11
v3.3.0
v3.2.2
v2.93.10
v3.2.1
v3.2.0
v2.83.20
v2.93.9
v3.1.2
v3.1.1
v3.1.0
v2.83.19
v2.93.8
v3.0.1
v2.93.7
v3.0.0
v2.93.6
v2.93.5
v2.83.18
v2.93.4
v2.93.3
v2.83.17
v2.93.2
v2.93.1
v2.83.16
v2.93.0
v2.83.15
v2.83.14
v2.83.13
v2.92.0
v2.83.12
v2.91.2
v2.83.10
v2.91.0
v2.83.9
v2.83.8
v2.83.7
v2.90.1
v2.83.6.1
v2.83.6
v2.90.0
v2.83.5
v2.83.4
v2.83.3
v2.83.2
v2.83.1
v2.83
v2.82a
v2.82
v2.81a
v2.81
v2.80
v2.80-rc3
v2.80-rc2
v2.80-rc1
v2.79b
v2.79a
v2.79
v2.79-rc2
v2.79-rc1
v2.78c
v2.78b
v2.78a
v2.78
v2.78-rc2
v2.78-rc1
v2.77a
v2.77
v2.77-rc2
v2.77-rc1
v2.76b
v2.76a
v2.76
v2.76-rc3
v2.76-rc2
v2.76-rc1
v2.75a
v2.75
v2.75-rc2
v2.75-rc1
v2.74
v2.74-rc4
v2.74-rc3
v2.74-rc2
v2.74-rc1
v2.73a
v2.73
v2.73-rc1
v2.72b
2.72b
v2.72a
v2.72
v2.72-rc1
v2.71
v2.71-rc2
v2.71-rc1
v2.70a
v2.70
v2.70-rc2
v2.70-rc
v2.69
v2.68a
v2.68
v2.67b
v2.67a
v2.67
v2.66a
v2.66
v2.65a
v2.65
v2.64a
v2.64
v2.63a
v2.63
v2.61
v2.60a
v2.60
v2.59
v2.58a
v2.58
v2.57b
v2.57a
v2.57
v2.56a
v2.56
v2.55
v2.54
v2.53
v2.52
v2.51
v2.50
v2.49b
v2.49a
v2.49
v2.48a
v2.48
v2.47
v2.46
v2.45
v2.44
v2.43
v2.42a
v2.42
v2.41
v2.40
v2.37a
v2.37
v2.36
v2.35a
v2.35
v2.34
v2.33a
v2.33
v2.32
v2.31a
v2.31
v2.30
v2.28c
v2.28a
v2.28
v2.27
v2.26
v2.25
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#118337
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?