You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
DESCRIBE THE BUG:
If there are long sequences with a clip Alpha = 0, the clip, text, or generator will still be computed despite not having any effect on the output. This additional Load is a huge waste of processing power. It wastes laptop battery, and CPU and GPU resources. This would also slows down playback during normal FCP use if this bug is present in the real time render pipeline, meaning lower FPS.
TO REPRODUCE:
Make a solid color background for a 6 hour long clip. Add 10 Text layers with large fonts or lots of texts for lots of rendering. Then set all the alpha of the text to 0.
Test 1:
Start timer.
Render on a consistent encoder setting.
End Timer
Test 2:
Start timer.
Disable all the text clips that are Alpha = 0.
Render on the consistent encoder setting above.
End Timer
You'll see that despite having the same resulting output, test 1 takes 80%-250% longer. Which depends on the complexity of the render.
EXPECTED BEHAVIOUR:
Unless a clip is explicitly used for its pixels in another pipeline, prior to alpha = 0 being applied, then a clip, text, or generator should be culled. It would be as if an Alpha = 0 were a programmatic way to specify that the clip is disabled. That correlation shouldn't but help performance stunningly
TESTING RESULTS:
I just got the results of the test in: when the alpha=0 clips are disabled, it takes 53 minutes to render. When the alpha = 0 clips are enabled, it was 86 minutes to render. i was expecting the alpha = 0 clips, titles, and generators to be optimized out of the render pipeline and there being no/marginal difference in render time.
Results vary depending on the clip count and complexity.
SPECS:
2021 16-inch MacBook Pro (M1 Max, 32GB RAM, 2TB SSD)
macOS Sonoma 14.6.1
Final Cut Pro 10.8.1
ADDITIONAL COMMENTS:
Apple's focus on efficiency, yet not optimizing the removal of Clips with alpha = 0 (with proper exceptions), is a contradiction. It's a simple thing that should have been implemented long many versions ago. If the export render pipeline is the same as the real time display (maybe with some different settings) then the real time display is getting half the frame rate it should have when clips are present but alpha = 0.
As stated, alpha = 0 clips should act like they are disabled within the render pipeline, for efficiency, unless otherwise required. If there is a good reason to waste cycles on alpha = 0 clips, i'd love to know.
This is such an obvious optimization, i considered calling it an enhancement, however because it's actually harmful to the electric bill, battery life and performance, silicon lifetime, user experience, render times, and deadlines, I consider this to be a huge and obvious bug.
And Apple, I am available for hire as a (software engineering) consultant or internal product review-tester.
The text was updated successfully, but these errors were encountered:
Apple Feedback Assistant ID: FB15619026
DESCRIBE THE BUG:
If there are long sequences with a clip Alpha = 0, the clip, text, or generator will still be computed despite not having any effect on the output. This additional Load is a huge waste of processing power. It wastes laptop battery, and CPU and GPU resources. This would also slows down playback during normal FCP use if this bug is present in the real time render pipeline, meaning lower FPS.
TO REPRODUCE:
Make a solid color background for a 6 hour long clip. Add 10 Text layers with large fonts or lots of texts for lots of rendering. Then set all the alpha of the text to 0.
Test 1:
Start timer.
Render on a consistent encoder setting.
End Timer
Test 2:
Start timer.
Disable all the text clips that are Alpha = 0.
Render on the consistent encoder setting above.
End Timer
You'll see that despite having the same resulting output, test 1 takes 80%-250% longer. Which depends on the complexity of the render.
EXPECTED BEHAVIOUR:
Unless a clip is explicitly used for its pixels in another pipeline, prior to alpha = 0 being applied, then a clip, text, or generator should be culled. It would be as if an Alpha = 0 were a programmatic way to specify that the clip is disabled. That correlation shouldn't but help performance stunningly
TESTING RESULTS:
I just got the results of the test in: when the alpha=0 clips are disabled, it takes 53 minutes to render. When the alpha = 0 clips are enabled, it was 86 minutes to render. i was expecting the alpha = 0 clips, titles, and generators to be optimized out of the render pipeline and there being no/marginal difference in render time.
Results vary depending on the clip count and complexity.
SPECS:
ADDITIONAL COMMENTS:
Apple's focus on efficiency, yet not optimizing the removal of Clips with alpha = 0 (with proper exceptions), is a contradiction. It's a simple thing that should have been implemented long many versions ago. If the export render pipeline is the same as the real time display (maybe with some different settings) then the real time display is getting half the frame rate it should have when clips are present but alpha = 0.
As stated, alpha = 0 clips should act like they are disabled within the render pipeline, for efficiency, unless otherwise required. If there is a good reason to waste cycles on alpha = 0 clips, i'd love to know.
This is such an obvious optimization, i considered calling it an enhancement, however because it's actually harmful to the electric bill, battery life and performance, silicon lifetime, user experience, render times, and deadlines, I consider this to be a huge and obvious bug.
And Apple, I am available for hire as a (software engineering) consultant or internal product review-tester.
The text was updated successfully, but these errors were encountered: