Bambu Studio Is Still Lagging — While Orca Keeps Fixing What Bambu Ignores

Bambu Lab Software Bambu Studio
1

Warning: long post ahead. But after years of lag, silence and half-measures, this deserves more than another vague reply. First, I will show what Orca has already fixed in the same codebase while Bambu Lab still leaves users with the same problems. Then I will set out what Bambu Lab now needs to do if you want any credibility back on this issue.

Purpose: Show exactly, point by point, which UI problems Orca Slicer has
addressed but which Bambu Lab Studio still has open in the same codebase.
With issue numbers, commit hashes, dates, and exact file:line references. No
rhetoric. Just evidence.

Date: 2026-04-20
Bambu Studio analyzed at: commit bf68eece1 (master, HEAD)
Orca Slicer analyzed at: commit 31c1c29325 (main, HEAD)
Verification: Every claim can be substantiated via git show <hash> in the clones.

Summary: Three Categories

  1. ORCA FIXED — BAMBU STILL HAS IT: Problems Orca explicitly addressed
    via PR or commit, and which are still present unchanged in Bambu’s public
    master.
  2. BOTH STILL HAVE IT — BAMBU USERS ASKED FOR A FIX: Problems reported by
    Bambu users years ago that still exist in both.
  3. BAMBU HAS AN INTERNAL FIX — NEVER PUBLISHED TO MASTER: The most
    critical category — Bambu HAS written the fix in their internal tree, but
    never released it to users.

CATEGORY 1: ORCA FIXED — BAMBU STILL HAS IT

1.1 Tab switch destroys the entire widget tree

Bambu issue: Implicit — reported in multiple blogs/forum posts as
“Prepare/Quality tab takes 1-3 seconds”
Orca issue improved: #997 “UI Slow to respond when changing settings tabs”

Bambu still has: Tab switching destroys and recreates the widget tree on
every switch.

Orca FIXED via PR #5386 (merged 2024-05-19):

  • File: src/slic3r/GUI/Tab.cpp, src/slic3r/GUI/Tab.hpp
  • Method: New deactivate() function that HIDES content instead of DESTROYING
  • Quote from PR description: “The Slicer GUI was destroying all the contents
    of a tab when going away and recreating it if you went back again. I have
    changed it so the contents aren’t destroyed, just hidden.”

The difference: Orca users report 1-second delay on tab switch. Bambu
users report 3+ seconds.

Time Bambu has been inactive: 23 months since Orca’s fix became publicly
available. No equivalent PR in Bambu’s master.

1.2 Continuous 100 ms timer in GLCanvas3D that runs always

Bambu issue: #10289 (April 2026) “Systemic UI slowness… ~37 wxTimer instances”
Orca handling: Implicit resolution — the timer is gone in the fork

Bambu still has (verified today):

// BambuStudio/src/slic3r/GUI/GLCanvas3D.cpp:10290
m_timer.Start(100, wxTIMER_CONTINUOUS);

Orca does NOT have this line. Grep verification in OrcaSlicer/src/slic3r/GUI/GLCanvas3D.cpp:

10107:    m_timer.Start(300, false);      // one-shot 300ms
10151:    m_timer.Start(300, false);      // one-shot 300ms

Orca runs a one-shot 300ms timer instead of a continuous 100ms timer.
That means 10 unnecessary UI-thread wakeups per second that Bambu users
suffer from, which Orca users don’t.

Time Bambu has been inactive: We don’t know exactly when Orca removed it,
but it is NOT in Bambu’s master today. Bambu users have reported UI sluggishness
since at least 2023.

1.3 Synchronous telemetry calls (track_event) — EXTREME CASE

Bambu issue: Implicit — contributes to #10289, #9967 (CPU spikes)
Orca handling: Explicit removal — ALL telemetry, not just in idle handler

Bambu still has (GUI_App.cpp:3299, 3307):

m_agent->track_event("mqtt_active", j.dump());
m_agent->track_event("mqtt_inactive", j.dump());

These run inside Bind(wxEVT_IDLE, [this](wxIdleEvent& event) {...}) and
call NetworkAgent::track_event() which typically makes an HTTP call to
Bambu cloud.

Verified via grep: Bambu’s GUI_App.cpp contains 11 track_event
calls. The entire BambuStudio/src/slic3r/GUI/ contains track_event in
10+ files including DeviceManager.cpp (8 calls), MainFrame.cpp (8 calls),
CalibrationPanel.cpp, Monitor.cpp, BBLTopbar.cpp and more.

Orca has 0 track_event calls in the entire OrcaSlicer/src/slic3r/GUI/.
Grep verification 2026-04-20 returned zero matches. They have removed all
telemetry, not just the two in the idle handler.

What this means for the user: Bambu makes telemetry calls on window
activation, slicing, calibration, device manipulation, filament switches,
and more. Depending on the NetworkAgent implementation, these can block the
UI thread. Orca users don’t experience this at all.

Be careful: This is not a UI fix in the strict sense — it’s an
architectural choice by Orca to remove all Bambu cloud telemetry. But it
reduces UI thread contention as a bonus effect.

1.4 wxWidgets is 1 year old (frozen fork)

Bambu issue: Implicit — misses a year of upstream bug fixes
Orca handling: PR #12941 merged 2026-03-30

Bambu still has (deps/wxWidgets/wxWidgets.cmake:27-28):

GIT_REPOSITORY "https://github.com/bambulab/wxWidgets"
GIT_TAG master

GitHub API verified 2026-04-20: latest commit in bambulab/wxWidgets is
2025-03-31. Over a year old.

Orca (deps/wxWidgets/wxWidgets.cmake:27-28):

GIT_REPOSITORY "https://github.com/SoftFever/Orca-deps-wxWidgets"
GIT_TAG v3.3.2

PR #12941 (merged 2026-03-30): “Upgrade wxWidgets to the latest 3.3.2. …
As Linux distros are moving to Wayland, and given the number of fixes in
wxWidgets to improve Wayland support, it’s worth upgrading to 3.3.2.”

Consequence for users: Wayland users on Linux (#8891, #11849, #13067 in
Orca) get a lot of improvements in Orca that Bambu users miss. wxWidgets
3.3.x has several years of improvements that nobody in Bambu gets.

1.5 Native Wayland support

Bambu issue: #8891 (unresponsive on Wayland after 2h), #2595 (Linux
Wayland support feature request since 2023)
Orca handling: PR #13197 “WIP: Add native Wayland support for Linux” (April 2026)

Bambu has: Nothing concrete in master. Issue #2595 has been open since 2023.

Orca has: Ongoing PR for native Wayland implementation. It replaces
wx’s default behavior with dedicated edge panels for window resize, which
solves the “resize only works on Prepare view” problem.

1.6 Multi-thread clipper (slicing performance)

Bambu issue: Implicit — contributes to #9469 (freezes whole system when
slicing mildly complex models)
Orca handling: PR #7177 “Upgrade clipper & improve multi-thread performance”
(merged 2025-06-18)

Bambu: No corresponding upgrade in public master.
Orca: Multi-threaded clipper library, ~10 months ago.

This doesn’t affect the UI thread directly, but faster slicing = less time
the UI is frozen while the user waits. In parallel, GUI updates run smoother.

1.7 Port of libvgcode (G-code viewer from PrusaSlicer 2.8)

Bambu issue: Implicit
Orca handling: PR #10735 merged 2026-01-06

Bambu: Uses original Bambu/Prusa fork viewer.
Orca: Ported the entire libvgcode from PrusaSlicer 2.8 — much more
modern GPU buffers, less memory, faster G-code preview rendering.

Not directly a UI freeze, but Orca users can scroll G-code without lag on
large models. Bambu users report slow G-code preview (implicit in #9933, #9191).

1.8 QoL: Hotkeys blocked in Prepare view

Bambu issue: Implicit, no open issue in Bambu
Orca handling: PR #12715 merged 2026-03-10

Orca fix: Hotkeys work even when notifications are displayed.
Bambu: Doesn’t have this fix.

1.9 Linux UX optimizations

Orca PR #12705 (2026-03-09): “Optimize linux experience”

  • Window resizing on all views (not just Prepare/Preview)
  • Fixed black screen on startup on Linux
  • Fixed Filament Grouping dialog appearing for all printers on Linux

Bambu: Has no corresponding Linux optimization in master. Linux users
report via #8891, #11849, #5526 (AppImage GTK exceptions), #9116 (Ubuntu
immediate crash on startup).

1.10 macOS-specific fixes

Orca PR #13215 (2026-04-15): “Fix macos crash on close”
Orca PR #11780 (2026-03): “OrcaSlicer clears user’s machine folder on
startup on macOS”

Bambu counterpart: #9188 (macOS mouse events) merged 2026-01-19 — one
fix. Several other macOS issues (#5397, #9652, #9757, #7513) are still
open.

CATEGORY 2: BOTH STILL HAVE IT — BAMBU USERS WAITING FOR YEARS

2.1 Monitor.cpp 1000 ms timer → stutters other apps

Bambu issue: #1950 — reported 2023-04 with exact root diagnosis
Age: 3 years open
Status: “Inactive 90d” — Bambu has NOT responded to the reporter

Bambu Monitor.cpp:

Line 37:  #define REFRESH_INTERVAL       1000
Line 162: m_refresh_timer->Start(REFRESH_INTERVAL);

Orca Monitor.cpp:

Line 39:  #define REFRESH_INTERVAL       1000
Line 165: m_refresh_timer->Start(REFRESH_INTERVAL);

BOTH have the same code. Orca has not fixed this either. But:

  • Orca has FEWER users complaining about this because Orca lags less overall
  • Orca has updated wxWidgets (3.3.2), which improves the event loop effect

But the fact remains: Bambu users have asked for this specific fix for
three years without response.

2.2 Plater.cpp wxMilliSleep(50) in UI thread loop

Bambu issue: F-005 in #10290 (April 2026)
Orca handling: Has not fixed this either

Bambu Plater.cpp:17073:

while (cont && cont_dlg) {
    wxMilliSleep(50);
    cont_dlg = dlg.Update(percent, msg);
    // ...
}

Orca Plater.cpp:12238:

while (cont && cont_dlg) {
    wxMilliSleep(50);
    cont_dlg = dlg.Update(percent, msg);
    // ...
}

Identical code. Neither has fixed this. But it’s an obvious UI blocking
pattern.

2.3 Synchronous app_config->save() in idle handler

Bambu issue: F-015 in #10290
Orca handling: Added m_post_initialized guard but NOT debouncing

Bambu GUI_App.cpp:3318:

if (app_config->dirty())
    app_config->save();

Orca GUI_App.cpp:3233:

if (m_post_initialized && app_config->dirty())
    app_config->save();

Both write to disk synchronously on every idle cycle if dirty is set.
Orca only has a guard against running it before initialization is complete.

2.4 27 unique wxTimer instances (timer proliferation)

Repo Number of unique new wxTimer()
Bambu 27
Orca 27

Neither has dealt with the fundamental timer proliferation. #10289 touches
on this point, but both repos have the same architecture.

CATEGORY 3: BAMBU HAS AN INTERNAL FIX — NEVER PUBLISHED

This is the most serious category. Bambu’s own developers have written
fixes but never released them in public master.

3.1 Page-fault reductions that exist in master but #3702 is still open

The following commits exist in Bambu’s master (verified via git log --grep "page fault"):

Date Commit Title
2024-08-12 66403ba19 ENH: Reduce the number of page faults on the device
2024-09-26 791be1954 ENH: Reduce the number of page faults in AMS
2024-10-09 542aa02ac FIX: fixed button not refreshing (page faults)
2025-02-08 ed1e9678c FIX: try to reduce page fault while idling
2025-02-10 b1fa2421c FIX: remove some unnecessary refresh to reduce page faults
2025-09-19 cefe97377 ENH: page faults when device page idle
2025-09-19 4dae5ff6d ENH: page faults when device page idle

Issue #3702 was reported 2023-09 and is still open 2026-04-20.

Conclusion: Bambu has fixed page faults seven times via point fixes
over two years, but the problem persists. This indicates the fixes are
symptomatic, not root-cause-based. If there was an architectural fix (like
S1/S2/S4 in report 4), issue #3702 would have been closed long ago.

3.2 Commits in Orca that are cherry-picked from Bambu internal

Interesting finding from Orca’s git log:

commit 7a197a3d8d
Author: tao ■■■■ <tao.■■■■@bambulab.com>
Date:   Thu Sep 26 20:57:42 2024 +0800

    ENH:Reduce the number of page faults in AMS
    
    Change-Id: I4bfb048ec62c35b515eecbb70c175fa0975d7f92
    (cherry picked from commit 791be195475bd834c937fb63341713529e4f41b8)

Interpretation: This is from tao.■■■■@bambulab.com — a Bambu employee!
The commit is cherry-picked from Bambu INTERNAL code. The Orca maintainer has
pulled from Bambu’s public master history.

So Bambu makes certain fixes internally and pushes to public master
sporadically. But in many cases where an issue reports a specific problem
(#1950, #3702, #3806), there is no commit that addresses the root cause
publicly.

Point: What Bambu Lab Actually Does

Bambu Lab are active developers. They have dev teams, they commit to public
master, they make page-fault fixes. But:

  1. No refactoring of Monitor.cpp despite #1950 for 3 years
  2. No refactoring of Plater.cpp despite its 23,675 lines
  3. No wxWidgets upgrade despite the fork being 1 year old
  4. No Wayland native paths despite Linux users’ complaints for 3 years
  5. No central timer scheduler despite 37+ wxTimer instances
  6. No debouncing of config save despite it being a 3-line fix
  7. Removal of 100 ms continuous timer — Orca did it, Bambu still has it
  8. Removal of telemetry in idle handler — Orca did it, Bambu still has it

Of these 8 points, 2 (#7, #8) are trivially easy fixes that take under
an hour to implement. They make a difference. Bambu has not done them.

Cadence of anger: what this says about priorities

Bambu’s communication with users is silent:

  • #1950 (2023-04): “Inactive 90d” — no comment from Bambu team
  • #3702 (2023-09): no root cause analysis published
  • #3806 (2023): no specific action
  • #8891 (2025-11): one comment from a Bambu collaborator referring to
    “create a DMP and send via ticket” — no technical diagnosis

Bambu’s actual activity: The team spends time on new features (H2D
support, AMS improvements, new printers) while performance issues get
symptomatic fixes instead of structural investment.

The market’s reaction: Orca has tripled Bambu’s GitHub popularity
(13,371 vs 4,294 stars) and has a third of open issues. This is not a
popularity in the Bambu Lab Studio community — users are fleeing to Orca.

Absolute demands on Bambu Lab — bullet list for immediate action

If Bambu Lab wants to keep its users, the following must happen in the
next release (2-4 weeks):

  1. Comment on #1950, #3702, #3806, #8891 with a timeline for action
  2. Debounce config save (3 lines of code, address: GUI_App.cpp:3318)
  3. Remove the 100 ms continuous timer (1 line of code: GLCanvas3D.cpp:10290)
  4. Remove track_event calls from idle handler (2 lines of code: GUI_App.cpp:3299, 3307)
  5. Upgrade wxWidgets to 3.3.2 (follow Orca’s PR #12941)
  6. Port back Orca PR #5386 (tab hide-instead-of-destroy)

Total implementation time for items 2-6: less than 2 weeks for a single
team member. If Bambu Lab can’t manage this after 3 years of complaints,
users can draw their own conclusions about the commitment.

Verification (for reviewers)

Every claim in this report can be checked:

  1. Clone both repos:
    git clone https://github.com/bambulab/BambuStudio.git
git clone https://github.com/OrcaSlicer/OrcaSlicer.git
  2. Verify the lines:
    grep -n "REFRESH_INTERVAL\|Start(100\|wxMilliSleep\|track_event" \
  BambuStudio/src/slic3r/GUI/{Monitor,GLCanvas3D,Plater,GUI_App}.cpp
grep -n "REFRESH_INTERVAL\|Start(100\|wxMilliSleep\|track_event" \
  OrcaSlicer/src/slic3r/GUI/{Monitor,GLCanvas3D,Plater,GUI_App}.cpp
  3. Verify wxWidgets version:
    grep "GIT_TAG" BambuStudio/deps/wxWidgets/wxWidgets.cmake
grep "GIT_TAG" OrcaSlicer/deps/wxWidgets/wxWidgets.cmake
  4. Verify Orca PR #5386:
    gh pr view 5386 --repo OrcaSlicer/OrcaSlicer
  5. Verify Bambu issue #1950:
    gh issue view 1950 --repo bambulab/BambuStudio

Closing word

The user who reported #1950 wrote in April 2023:

“I do see a 1000 ms timer refresh event in Monitor.cpp, perhaps there is
an issue in the way the timer event and wxWidgets are being used that may
have negative externalities on other apps?”

The reporter identified exact file and exact problem. It took 10 seconds
to identify. Bambu Lab has had 3 years to fix it.

Three years.

Reports 1-4 describe what is technically wrong and how it can be fixed. This
report documents what is organizationally wrong. Bambu Lab has an active
development team with competence — but UI performance is not their
priority. Their users’ tormented reports show that it should be.

References

All issues and PRs verified via gh issue view / gh pr view 2026-04-20.

Commits in Bambu master (verified via git log --grep):

  • 66403ba19 (2024-08-12), 791be1954 (2024-09-26), 542aa02ac (2024-10-09)
  • ed1e9678c (2025-02-08), b1fa2421c (2025-02-10)
  • cefe97377, 4dae5ff6d (2025-09-19)

Audience: Bambu Lab Studio development team
Date: 2026-04-20
Status of the problem space: Systemic, multi-year, inadequately addressed
Analyzed commit: bf68eece1 (master, HEAD)

TL;DR

The UI performance problems in Bambu Studio are not unsolvable. Orca Slicer —
a fork of your own codebase — delivers a noticeably more responsive UI through
a handful of concrete structural choices you can adopt. But it requires you to
prioritize it. You have had root-cause diagnoses like #1950 (Monitor.cpp
1000ms timer) open since 2023; #3702 (page-fault storm) since 2023; #3806 since
2023. This is not a technical difficulty — it is a prioritization problem.

This plan is divided into three time horizons:

  • Immediate (within 1 week, minimal risk)
  • Short-term (within 1 month, moderate risk)
  • Long-term (3-12 months, structural investment)

Each action is tied to concrete file:line references and relevant open issues.

Immediate Actions (within 1 week)

I1. Debounce app_config->save() in the idle handler

File: src/slic3r/GUI/GUI_App.cpp:3318
Issue: Contributes to #3702 (page faults), #9967 (CPU spikes every minute)
Risk: Very low

Problem: save() runs synchronously on the UI thread every time the idle
handler fires and dirty() is true. In the worst case this can result in
dozens of disk flushes per second.

Action: Add time-based debouncing (5-second interval).

// Suggested (pseudo)
static wxLongLong last_save_time = 0;
wxLongLong now = wxGetLocalTimeMillis();
if (app_config->dirty() && (now - last_save_time).GetValue() > 5000) {
    app_config->save();
    last_save_time = now;
}

I2. Remove track_event from idle handler

File: src/slic3r/GUI/GUI_App.cpp:3299, 3307
Issue: Potential UI-thread blocking via NetworkAgent
Risk: Low — only telemetry data is affected

Action: Follow Orca’s lead — remove these lines:

m_agent->track_event("mqtt_active", j.dump());   // LINE 3299
m_agent->track_event("mqtt_inactive", j.dump()); // LINE 3307

Or move them to an async background thread if they must remain:

std::thread([agent = m_agent, event_name, json_data]() {
    agent->track_event(event_name, json_data);
}).detach();

I3. Stop the 100 ms continuous timer in GLCanvas3D

File: src/slic3r/GUI/GLCanvas3D.cpp:10290
Issue: #10289 (~37 wxTimer instances problem)
Risk: Low — Orca has already removed this

Problem: m_timer.Start(100, wxTIMER_CONTINUOUS) starts a timer that
fires 10 times per second continuously. Together with other timers this
contributes to persistent UI-thread activity.

Action: Convert to StartOnce only when layer editing is actually active:

// Original:
m_timer.Start(100, wxTIMER_CONTINUOUS);

// Suggested:
if (is_layer_editing_active()) {
    m_timer.StartOnce(100);
}

I4. Review startup time for the Network Plugin

Issue: #8160, #8605, #8390 (slow startup)
File: relevant points in src/slic3r/Utils/NetworkAgent.cpp
Risk: Medium

Problem: libbambu_networking.so loading causes split-lock errors on
modern CPUs and takes several seconds to initialize.

Action: Lazy-load the network plugin only when the first network call is
needed, not at app start. Display the UI while plugin loading proceeds in the
background.

I5. Ensure all timers stop in Show(false)

File: every file that starts timers (see bevis/bambu-timer-inventory.md)
Issue: #10289
Risk: Low, but requires granular review

Problem: Some panels start timers but don’t bind Stop() to
Show(false)/hidden state. Examples: MultiMachinePage, SendMultiMachinePage,
ThermalPreconditioningDialog.

Action: Do a full audit — every timer->Start(N) should have a matching
timer->Stop() in panel-hiding / panel-destruction paths.

I6. Address #1950 publicly

Action: It has been 3 years since an external user pointed out the
1000 ms Monitor.cpp timer as the cause of UI problems affecting other apps.
Comment on the issue with either a planned fix or an explanation for why
it’s difficult to change. Three years of silence erodes trust.

Short-term (within 1 month)

S1. Centralize timers into a common scheduler

Issue: #10289 (timer proliferation)
Risk: Medium — touches many panels

Problem: 27 unique new wxTimer() + 230 wxTimer references across 92
files. Each timer has its own wxEVT_TIMER event going through the event
loop. This scales poorly when many panels are open simultaneously.

Action: Implement a central UiScheduler that manages all periodic tasks:

class UiScheduler {
public:
    using JobId = size_t;
    JobId schedule(std::chrono::milliseconds interval,
                   std::function<void()> callback,
                   bool only_when_visible = true);
    void cancel(JobId);
private:
    // Single wxTimer driving all callbacks
    wxTimer m_driver_timer;
    std::vector<Job> m_jobs;
};

Panels register instead of owning their own timers. Hidden panel = no
callbacks. This eliminates the #10289 problem in one sweep.

S2. Move device polling to a background thread

File: src/slic3r/GUI/Monitor.cpp
Issue: #1950, #10289
Risk: Medium — requires thread-safe DeviceManager

Problem: Monitor::on_timer → update_all() does synchronous queries on
the UI thread every second. The result is that other apps stutter when
Bambu Studio is open.

Action:

  1. Move update_all() to a background thread that polls once per second
  2. When data updates, wxQueueEvent(panel, new DeviceDataEvent(...)) for UI
    update
  3. The UI thread does no synchronous I/O; it just renders the latest snapshot

S3. Audit 17 synchronous .perform() HTTP calls

Files: GUI_App.cpp, BindDialog.cpp, StatusPanel.cpp,
WebViewDialog.cpp, HelioDragon.cpp
Issue: #10289, potentially #8891, #9453
Risk: Medium — affects error paths

Problem: These calls block the calling thread for the full HTTP
operation. If they run on the UI thread directly or indirectly → UI freeze.

Action: Go through every call site and verify:

  1. Does it run on the UI thread?
  2. If yes, move to a background thread with std::async or boost.asio
  3. Use wxQueueEvent for UI update when the operation completes

S4. Upgrade wxWidgets to 3.3.x

File: deps/wxWidgets/wxWidgets.cmake:27-28
Risk: High — many small behavior differences between versions
Time investment: 1-2 weeks

Problem: Bambu’s wxWidgets fork was last updated 2025-03-31 — over a year
ago. Orca migrated to v3.3.2 via PR #12941.

Action: Follow Orca’s example:

  1. Merge upstream v3.3.2 into the bambulab/wxWidgets fork
  2. Test on all platforms (Windows, macOS, Linux) with CI
  3. Cherry-pick Bambu’s own improvements on top of the 3.3.2 base

S5. Lazy-load the Network Plugin

Issue: #8160, #8605, #8390
Risk: Medium

Action: Load the plugin only when the user needs it (Device tab,
Login dialog) — not at app start. Show the UI immediately.

S6. Debounce file I/O and unnecessary Refresh()

Files: several (see grep for Refresh())
Issue: #3702 (page faults)
Risk: Low

Problem: Bambu’s commit history shows several fixes like “remove
unnecessary refresh to reduce page faults” (b1fa2421c, ed1e9678c, etc.).
These fixes are point fixes. Do a systematic audit with git grep Refresh()
and identify every call that can be replaced with RefreshRect() or
eliminated entirely.

Long-term (3-12 months)

L1. Split Plater.cpp into logical modules

File: src/slic3r/GUI/Plater.cpp (23,675 lines, 163 includes)
Issue: Implicit — contributes to #3702
Risk: High — affects a large surface of the code
Time investment: 3-6 months

Problem: The “god object” file has such large instruction cache pressure
that hot paths generate thousands of page faults per second. Splitting it is
not just a cleanliness argument — it is a performance concern.

Action: Split by responsibility:

  • PlaterModel.cpp — state management
  • PlaterUIView.cpp — widget hierarchy
  • PlaterRender.cpp — 3D rendering
  • PlaterJobs.cpp — async jobs (slicing, upload)
  • PlaterDialogs.cpp — inline dialogs

L2. Split GLCanvas3D.cpp

File: src/slic3r/GUI/GLCanvas3D.cpp (13,560 lines, 69 includes)
Risk: High

Action: Same principle — render, input handling, gizmos, picking, and
ImGui integration should be separate.

L3. Introduce clang-tidy + cppcheck in CI

Issue: Issue #10290 identified several classes of problems static
analysis could catch
Risk: Low (only produces reports)

Rules to enable:

  • bugprone-empty-catch
  • performance-*
  • misc-unused-parameters
  • cppcoreguidelines-* (selective)

Even though some of issue #10290’s early findings were retracted via errata,
clang-tidy is still valuable for future regression protection.

L4. Introduce performance regression tests in CI

Action: Build a test that:

  1. Starts the app
  2. Loads a standard 3mf
  3. Switches between tabs X times
  4. Measures idle CPU and page faults with perf/WPA

Failure if regression is detected. This blocks new #3702-like problems.

L5. Move the slicing process to a dedicated worker process

Issue: #9469 (freezes whole system when slicing mildly complex models)
Risk: Very high
Time investment: 6-12 months

Action: Instead of slicing on a worker thread inside the app process,
spawn a separate OS process that runs slic3r core and communicates via
pipes/IPC. Benefits:

  • A slicing crash doesn’t take down the whole app
  • The OS scheduler can prioritize the slicing process separately
  • The UI process remains fully responsive

L6. Introduce structured telemetry (opt-in) for performance

Action: Collect anonymous frame-time data, idle CPU time, page fault rate.
Users opt in. This gives you your own data instead of having to extract it
from issue reports.

Specific PRs/commits from Orca worth porting back

The following Orca commits/PRs solve problems relevant to Bambu and are
relatively low-risk to port back:

Orca source What it does Bambu file to change
PR #5386 (2024-05) Tab::deactivate() — hide tab instead of destroy Tab.cpp, Tab.hpp
PR #12941 (2026-03) wxWidgets 3.3.2 upgrade deps/wxWidgets/wxWidgets.cmake
PR #12705 (2026-03) Linux resize/window fixes MainFrame.cpp
PR #12715 (2026-03) Fix hotkeys blocked in Prepare view relevant input handler
PR #11887 (2026-01) Memory opt for small loops slicing core
Commits removing 100ms timer in GLCanvas3D Fewer UI thread wakeups GLCanvas3D.cpp:10290
Commits removing track_event in idle handler No synchronous telemetry in idle GUI_App.cpp:3299-3307

Measurable goals (KPIs)

If you implement the proposed changes:

KPI Baseline (now) Target after 3 months
Idle CPU (desktop, no activity) ≥5% (per #3806) <1.5%
Page faults per second in idle 1000+ (per #3702) <50
Tab-switch time 1-3 s (per #997 for Orca, worse in Bambu) <100 ms
Startup time to usable UI 10-30 s (per #8390) <3 s
Open issues with “freeze/lag/slow” in title 100+ <30

Prioritization recommendation

If you can only do one thing in the next sprint — do I1 + I2 + I3
(debouncing + remove track_event + stop 100 ms timer). Together they take
less than a day to implement and address multiple high-profile issues.

If you have two weeks — add S1 (central scheduler). It solves timer
proliferation permanently.

If you have a month — add S4 (wxWidgets upgrade). It’s the single
biggest lever.

If you have half a year — add L1 + L4 (Plater.cpp split + CI regression
tests). That’s the structural reinforcement that keeps the problems from
coming back.

Communication with users

Your users are frustrated. Several high-profile issues (#1950, #3702, #3806,
#8891) have been open for a year or more without response. Use one of them
to show that you’re listening:

  1. Comment on #1950, #3702 with “we have a plan, here are the milestones”
  2. Open a meta-issue titled “UI performance improvements 2026: tracking”
  3. Update that meta-issue weekly with actual fixes that land

Silent development after 3 years of complaints rarely turns users around;
visible iteration does.

Closing remark

Your users are not wrong. The problems are real, documented, and have
concrete root causes that can be addressed. Your own fork Orca Slicer has
proven it. There is no technical reason Bambu Studio needs to keep freezing
year after year.

Take ownership of the codebase.

References

Issues

Pull requests (Orca)

Code references (Bambu HEAD bf68eece1)

  • src/slic3r/GUI/Monitor.cpp:37,162,281,461
  • src/slic3r/GUI/GLCanvas3D.cpp:10290,3935-3984
  • src/slic3r/GUI/Plater.cpp:17073
  • src/slic3r/GUI/GUI_App.cpp:3291-3320
  • deps/wxWidgets/wxWidgets.cmake:27-28
18 Likes
Bambu Studio 2.4, 2.5 Borderline Unusable, Too Slow
2

Wow, nice plan. Some of the issues are indeed egregious. (The thing with “internal” changes is also very curious, I noticed that as well.) The code itself is so full of inefficiencies and other more minor mistakes or awkward syntax or repeated code… I cringe and develop twitches each time I work with it (it’s very hard to keep from changing irrelevant code, to keep PRs clean). Besides everything listed here, the code base needs refactoring in multiple locations. (It’s not just a style thing – messy code is harder to read and leads to more mistakes down the line. DRY is an acronym to live by.) Yea… 20K+ line cpp file… don’t see that every day (thankfully!)… and yet it keeps getting unrelated code added to it (eg. Helio stuff).

–

I would add getting rid of the dozens of compiler warnings when building Studio into at least one of the categories (preferably sooner). Some are actually relevant and should be fixed, and the irrelevant ones properly dealt with by compiler switches/pragmas. Having worked with the code, this is not only annoying, but makes it very difficult to pick out warnings about any code changes one has made (and I suspect one reason for new code smells being introduced). There’s an outdated PR for some of this, but never got any traction. Orca fixed some, but still lives with others, somehow, it seems. I don’t understand that at all… those warnings are the last line of defense, so to speak, ignoring them or burying them is irrational.

–

Sorry… so minor in the scope of things… but like I said, I can’t help myself… :flushed_face:

   if (app_config->dirty() && (now - last_save_time).GetValue() > 5000) {
+      last_save_time = now; 
       app_config->save();
-      last_save_time = now;
   }

–

I hope your posts prompt some action, even if I admit to be skeptical. I suspect BL knows all this already (they do have a bot to tell them about it, anyway, and apparently at least some experienced programmers somewhere). Why they let it get this bad though, is a mystery. It’s still fixable, but just barely. Ultimately it needs to be rebuilt on top of a more modern x-platform GUI library, keeping the core slicer code. I hope “someone” is doing that now. I’d like to, but it’s way too big for one person ofc.

Cheers,
-Max

4 Likes
3

@SupportAssistant

Why has Bambu Lab remained so quiet about problems of this magnitude?

You have locked customers into software that, for some of us, is no longer fit for purpose. When a product is tied to software that does not function properly, and the customer is effectively prevented from using the product as intended, that is not a minor inconvenience. It raises a serious conformity issue.

At present, I cannot use Bambu Studio on any of my computers. That means I am left with a product that cannot be used in the way it was sold and marketed. Any serious company should understand how alarming that is. Bambu Lab, however, appears to have chosen silence.

Let this be the polite version.

If there is no rapid and meaningful improvement from Bambu Lab, I will make my technical findings public in a far more comprehensive form. I am also prepared to share my knowledge with EU customers who may be considering formal action to rescind their purchases. Yesterday, I spent time with legal counsel refining the framework for a broader matter should this situation continue unresolved.

Bambu Lab should think very carefully about where this leads. If a large number of EU customers are left with products that cannot be used as intended because of software lock-in and persistent defects, the financial exposure may be substantial. We are not talking about a token gesture or a goodwill coupon. We are talking about refunds, formal consumer claims, and a level of scrutiny that could have a very real commercial impact.

The fastest and simplest way for Bambu Lab to start rebuilding trust would be to remove the lock-in to Bambu Studio. That would at least allow customers to continue using the products they paid for while Bambu Lab fixes its software properly.

As things stand, Bambu Lab can hardly claim that this forced software dependency meets the standard of quality customers are entitled to expect.

1 Like
4

I am having a really hard time understanding what the problem is that you are attempting to solve. I have been using Bambu Lab printers for around three years now and can’t say that I ever thought that Bambu Studio was lagging or otherwise defective. Quite the contrary, I have models that were printed early on, and ones that have been recently printed and see a noticeable improvement in the quality of the print.

You write things like:

Yet I have been using my Bambu Lab printers in the same way as they were marketed and sold, and my printers work very well, much better than originally expected.

And then this threat:

Who do you think you are? Some tough guy that bullies others into doing your bidding? That companies tremble in your wake? It is very hard for me to take seriously those who make such threats. Especially when one’s underlying arguments don’t square with reality. From your narrative one would get the idea that Bambu Studio barely functions. Yet here it is, on my computer and it works without issue every time I want to use it, and it has for the last three years. From where I sit, It is as if you are threatening Bambu over your delusions, over your misunderstandings. .

You must know as you, or your AI assistant, have demonstrated, that most code is meaningless to most people, as well as being generally meaningless without context, and by showing snippets of code and insisting it means one thing or another is kind of a common scam. It is a bit like writing out sciencey looking equations, while talking gobbly-goop.

5 Likes
5

Ah, the person who tried to tell me I didn’t know what I was talking about when I raised similar issues. I ignored you last time, but it’s harder this time. I’m honestly not sure if you’re shilling for Bambu or what. You’re the one that said to expect crap code from all open source projects, right? Basically insulting every OS developer who ever existed and displaying your ignorance at the same time.

Anyway, I’m really glad it works great for you. It works for me too. But perhaps before posting your good news, you could take the time to read some other recent threads here and determine that’s not the case for everyone, by a long shot. Or look at the issues on GitHub. Not everyone is as lucky as you and I, especially with recent releases.

The OP here is clearly meant for Bambu developers (or other devs). If you don’t understand it, why comment? It’s all backed up by evidence, and not that you’ll believe me, but it’s also correct.

I do think that threatening legal action in public like this is probably counterproductive and pretty much ensures BL will never respond. Oh well. But the issues are real, whether they affect you personally or not.

-Max

1 Like
6

I see in @L0rdS474n’s post a lot of frustration. While I concur that “demands” are kind of silly, I get the frustration about years-old bugs being ignored in favor of new product development. I think that they are trying to make it easy for Bambu to fix these specific bugs.

Bambu gives us unusual insight into their development (thank you, GPL!). And because of that, @L0rdS474n is able to dig into the project and identify issues. That is an enormous amount of free work and I really hope someone in the software team’s product management takes advantage of it.

However, I also am not really surprised that we’re in this spot. Pretty much all commercial software has this problem: new product features get prioritized over bug fixes. There are known bugs in Windows and macOS that have been around for over a decade. They’re real bugs, but they never get fixed, and they probably never will.

If you are never affected by the bugs, that’s great! I’m very happy for you! But that doesn’t mean that other people aren’t experiencing real problems.

I think @L0rdS474n is tilting at windmills, but I admire the attempt. It might even work. Most people just complain and move on (or complain incessantly, always an option). Lordy has actually tried to do something useful and constructive.

3 Likes
7

You seem more offended by the existence of criticism than by the underlying defects.

This is not about swagger, and it is not about intimidation. It is about a vendor being confronted with specific, testable, technically grounded criticism after years of user complaints.

Your entire rebuttal boils down to: “it works for me.” Good. Then you are fortunate. But personal luck is not a substitute for analysis, and it does not cancel public issue history, reproducible reports, or observable differences in a fork of the same codebase.

You call it a scam to cite code without context. I provided context: repository, commit, issue history, file paths, exact lines, and cross-reference to Orca’s changes. In other words, enough information for anyone serious to verify or challenge each point. That is called evidence, not theatre.

And no, this is not about making companies “tremble.” It is about reminding companies that dismissing persistent defects, while continuing to sell a software-dependent product, has consequences. Technical, reputational, and in some jurisdictions legal.

So spare me the amateur psychology.

If the analysis is wrong, refute it properly. Quote the file. Quote the line. Quote the commit. Explain the actual behaviour. Show where the reasoning fails.

Until then, “works on my machine” remains what it has always been: a cliché, not a counterargument.

3 Likes
8

Thank you — that is a fair and thoughtful comment.

Yes, I am frustrated, and I do not think that is unreasonable. When the software you are expected to rely on has become extremely difficult to use, and when a printer that is less than a year old has already needed replacement of nearly every part, frustration is a fairly natural response.

Some may see this as “tilting at windmills,” but my view is that if nobody takes the time to document the problems properly and show how longstanding issues are being left unresolved while new functionality continues to be added, then the situation simply continues unchanged.

Bambu Lab has stated that new features are supposed to be tested carefully so that existing functionality is not affected. If that process were working as well as claimed, the current state of the software would look very different.

I still hope this can be resolved without escalation. My preference is for Bambu Lab to fix the software issues, address the remaining product problems properly, and engage transparently with users. Legal options exist as a last resort, and I have prepared for that possibility, but I would much rather see practical solutions than formal disputes.

I have been through a legal matter with Bambu Lab before, and it ended in a settlement. Given the current situation, I am less willing to assume that the same kind of resolution would be acceptable again.

So while I understand the “windmills” comparison, I think these issues need to be documented and pressed. Otherwise they are simply ignored, and users are left to absorb the cost in time, money, and effort.

1 Like
9

Yet, the sky still isn’t falling, is it?

Having grown up professionally in the R&D world, I see things differently. In any project, be it software, electrical, mechanical, architectural, or whatever, there are times when it is decided to make alterations to the original design. Yet when one goes back and changes things designed early on, there tends to be a rippling effect that can’t always be predicted. The larger and more complicated a system becomes, the more ripples one has to concern oneself with.

Unless one is to rebuild a project from the ground up on every iteration, things get left in. Sometimes taking them out creates more problems. It is said that at the core of window is DOS, warts and all. It tends to be more efficient to build changes on top of a stable system.

As to coding itself, I find such arguments to be a little silly. One of the beauties of computers, be it in coding, or in design, or whatever, there are always different ways to do things. More than one way to skin a cat, as the saying goes. When someone makes claims such as, “the other guy does this, but my way is better”, tends to fall along the line of personal preference.

These complaints against Bambu tend to ring hollow when reality presents a different story. At some point one has to ask oneself, if Bambu is so bad, and has all these problems, how is that Bambu Lab printers have become the most popular and most influential 3D printer the world over? I can design models and publish them to MakerWorld and all around the world people can print those models with the same quality as the ones printed on my printers. So it doesn’t just work on my machine, it works on a lot of other people’s machines as well.

1 Like
10

I do not disagree with the general engineering point that legacy code, design carry-over, and ripple effects are normal in large systems. They are. But that does not invalidate the criticism.

Bambu Studio is not a greenfield application. Bambu Lab states that it is based on PrusaSlicer, which is itself based on Slic3r, a project dating back to 2011. So we are discussing a code lineage of roughly fourteen to fifteen years, not a brand-new foundation. That is not automatically a problem. The problem begins when inherited complexity is not managed well enough.

And this is where the “these complaints ring hollow” argument falls apart. I do not know how many users experience no issues at all. What I do know is that Bambu Studio’s own public repository shows 5,000+ issues, with open examples going back to 2023 and 2024. That does not prove every user is affected. It does prove the backlog is real, longstanding, and far too large to dismiss as mere personal preference.

Popularity also does not refute technical debt. It only proves that the hardware is strong enough, and the ecosystem attractive enough, that many users are willing to live with more software debt than they otherwise would. Those are not the same thing.

And for the record, the Windows/DOS analogy is not a very good one here either. Early Windows versions depended on DOS, but the modern Windows NT line has been architecturally independent of MS-DOS for decades.

So no, the issue is not that Bambu Studio has ancestry. Nearly all serious software does. The issue is that a mature product with a large inherited code lineage still appears to carry a substantial unresolved defect backlog in its own public tracker, while some people keep trying to dismiss concrete criticism as if it were just a matter of taste.

2 Likes
11

It is not like you haven’t repeatedly given yourself away. It seems to me that Orca users tend to have problems with their printers that others do not. It almost makes me think that if I loaded Orca on my computer, that I too would end up with all manner of unexplained problems.

4 Likes
12

That is not a serious argument. It is just insinuation.

You are not rebutting the substance of the criticism at all; you are trying to discredit the people raising it. “Orca users tend to have problems” is not evidence. It is an anecdotal generalisation dressed up as analysis. If you want to argue that Orca causes specific failures, then show reproducible cases, isolate the variables, and demonstrate causation. Otherwise, this is just guilt by association.

It is especially weak given that OrcaSlicer itself openly states that it grew out of the BambuStudio/PrusaSlicer/Slic3r lineage, while Bambu Studio also states that it is based on PrusaSlicer and, before that, Slic3r. So presenting Orca as though it were some foreign contaminant that mysteriously infects printers is not a technical argument. It is theatre.

And no, popularity does not disprove technical criticism either. A product can be commercially dominant and still carry significant unresolved software debt. Bambu Studio’s own public repository shows 5k+ open issues. That does not prove every user is affected, but it certainly makes it impossible to dismiss criticism as though it were just a hobbyhorse of a few “Orca users”.

So unless the claim is backed by controlled comparisons, logs, reproducible G-code differences, and a clear causal chain, it amounts to little more than: “I do not like the people making the argument, therefore the argument must be wrong.” That is rhetoric, not engineering.

3 Likes
13

It is one of most baffling things. The sustained effort to paint Bambu in a bad light. When you bought your phone, did you disassemble the code and pick it apart? Did you disassemble the code in your microwave or washing machine and demand the manufacturer change their code to meet your approval?

It’s not like there isn’t a paper trail. Not like it is such a strange mystery. If the open source community was all that, something other than tinkerer clones would have been developed by now. Seems to me that there is a certain crowd of people who seek to steal Bambu technology away and claim it as their own.

People like you keep insisting that Bambu has all these problems that I never see. And I have five printers. Never had a problem with Bambu Studio. These machines were designed to be user friendly and I find them to be just that. I have found my Bambu printers to be highly repeatable - even between different models. Even though I design things with tight tolerances, they always print well on standard Bambu printers. The printers work so consistently and predictably well that I never have to worry about them. Allowing me more time to spend on design, rather than wasting it tweaking my printers.

Even though you claim that Bambu won’t let you use the printers as they were marketed and sold, I get the idea that you missed the boat and have been left standing on the wrong side of history. The future of 3D printing, consumer 3D printing, is average people downloading things off of places like MakerWorld and printing the objects themselves, without the need for technical expertise or design knowhow. It is central to the replicator concept.

I find that Bambu Studio works really well at organizing large complicated projects, that Bambu 3mf files encapsulate multi-bodied multi-colored models very well, making the experience for the end user as seamless as possible. Load your filament and print profile, select the plate, hit print and away you go. In all your ranting, I have yet to see anything that disrupts that process.

2 Likes
14

What you have written is not a rebuttal. It is a long attempt to delegitimise criticism by attacking the people making it instead of addressing the defects being raised.

Your entire argument boils down to: “my printers work, therefore the reported problems do not matter.” That is not analysis. It is anecdote elevated to doctrine.

No, users do not need to disassemble a microwave to complain when it fails. But when a company makes software a core dependency of the product, and that software is released in a way that allows inspection, users are fully entitled to examine it, identify faults, and present evidence. That is not hostility. That is accountability.

The “you just want to steal Bambu’s technology” line is especially weak. Criticism is not theft. Pointing to bugs is not sabotage. Referring to concrete implementation problems is not some ideological attack on the company. It is called discussing the product on its merits.

Your argument also relies heavily on personal satisfaction as though it settles the matter. It does not. “I have five printers and never see these issues” says something about your own usage. It says nothing at all about whether other users are encountering real, reproducible problems. A defect does not cease to exist because it has not happened to you personally.

And the point about “the future of consumer 3D printing” is a complete diversion. Nobody is arguing against simple workflows, accessible printing, or ordinary users downloading files and pressing print. The criticism is that when the underlying software has documented weaknesses, dismissing them with brand loyalty and hand-waving is not a serious answer.

So let us strip away the theatrics and get back to the only question that matters: are the reported issues real, reproducible, and supported by evidence? If not, show where the evidence fails. If they are, then “works for me” is not a rebuttal. It is just noise.

You are defending the brand. I am discussing the substance. Those are not the same thing.

1 Like
15

Is anyone else’s Bambu Studio lagging really bad all of a sudden? Mine just started. It also takes forever to slice.

16

You are familiar with the naturalistic fallacy, right? Because something exists does not make it good or correct.

17

ie Trolls

Screenshot 2026-04-22 103901
Screenshot 2026-04-22 103901889×472 43.2 KB

1 Like
18

If McDonalds is so expensive and creates all these health problems for consumers, how is that McDonalds has become the most popular and often eaten food vendor the world over?

2 Likes
19

@Alweg223 I’m not having any problems, running 2.6.0.51 on Windows 11. I’ve seen a couple of other people post similar to you, but I’m thinking they were using MacOS, not sure, there could be something going on, but I haven’t experienced it.

20

Cause “Murica” :grinning_face_with_smiling_eyes:

Bambu became popular because it’s a 1 click printer for the average Joe that does not even know what is an extruder or anything else that is not PLA (just look at some newcomers questions around the forum). That’s it. Since then everyone is a “modeler” or a “creator” because of how easy it is to print on Bambu printers.
It does not mean that there aren’t problems.

And i agree with the take on this topic. If Bambu wants to create an ecosystem where their software MUST be used by the same thousands that use their printers, then the software must work accordingly with every supported machine. The easy way would be to open their minds to the software side of things and concentrate on the hardware, but we all know how it works and a Studio vs Orca war would begin and that is not the point of this.

Waiting for a fix that has been reported a year ago is not an option and since their printers is being used by everyone (from mothers to grannies), their software should (MUST) be getting more attention instead of adding new crap that no one needs (Helio for example). Grannies and common neighborhood mommies won’t search for a bug fix and instead will rely on the software that the brand tells them to use.

Not everyone will have problems but some do. I have several computers and as weird as it seems, Bambu Studio is mostly stupidly slower on the high end machines, although there is enough horse power to chug it along. On an i7 4770k with a GTX1080 it works perfect while on the same cpu with a RTX3060 is slow. Why and how?

Or better yet. A Ryzen 9800X3D with 128Gb of ram and 2 RTX4090’s has been the most problematic, even though it’s the most capable of the systems. All rigs use the same OS version, even tested with Linux and it still is problematic. Not everyone has a problem but i sure do and until now i have never said anything because i have seen that those who talk about it (for over a year at least) are not taken serious and all the white knights come right away to defend Bambu… Why? Is there money involved or are people so blind that can’t see that problems do exist and there is no “perfect” brand?

Note: i eat McDonalds once every few months, if that matters :grinning_face_with_smiling_eyes:

1 Like