6 seconds for a change is something you need to throw a kitchen sink of UX techniques at for sure, especially if it’s the kind of change the user wants to itera

6 seconds for a change is something you need to throw a kitchen sink of UX techniques at for sure, especially if it’s the kind of change the user wants to iterate on. If there’s multiple dials to change, debounce and throttle aggressively to batch together as many design changes as possible. Show a progress bar - O(n^2) algorithms suck in most regards, but one advantage is they are ideal candidates for progress bars. Initialize the bar with n steps and put a call to tick() in the outer loop, you get a very truthful and satisfying progress bar. Take a page from web dev: don’t block the main thread. Let the user move the view around while it’s recalculating. Let the user make another design change while it’s recalculating (just start the recalculation over if they do). For inspiration on hardcore stuff you can do to handle this “user wants to make iterative changes but each change involves heavy computation” problem, you can check out Affinity Photo. They go to extreme lengths in the pursuit of “feels like real-time feedback”, like taking a heavily scaled down copy of your image and applying the filter to that so they can show you an approximate preview of the final result while it’s computing. This is probably more effort than just making a better algorithm though.