Fluid Ardule, 화면을 새로 그리지 않는 것이 최고의 최적화였다

이 이미지는 TFT-LCD에 표시 중인 이미지를 파일로 저장하게 만드는 유틸리티('capture_fb1.py')를 사용하여 얻은 것이다.

Fluid Ardule의 개발을 하다 보면 예상했던 곳보다 전혀 엉뚱한 곳에서 병목을 만나는 경우가 있다. 최근 Yoshimi를 탑재하면서 이상한 현상이 나타났다. 같은 패치를 커맨드 라인의 Yoshimi에서 직접 실행하면 아무 문제가 없는데, Fluid Ardule 안에서만 간헐적으로 클릭 노이즈가 발생했다. ALSA 연결을 의심했고, aconnect 설정도 살펴봤으며, 실행 옵션도 하나씩 비교했다. 하지만 원인은 좀처럼 드러나지 않았다.

결국 의심을 거듭한 끝에 아주 단순한 실험을 해 보았다. TFT-LCD의 화면 갱신을 시험적으로 완전히 멈추어 보았다.

결과는 예상 밖이었다. Python 프로세스의 CPU 사용률은 약 50~60%에서 2% 수준으로 떨어졌고, Yoshimi의 글리치도 함께 사라졌다. 범인은 오디오 엔진이 아니라 UI였다.

생각해 보면 이는 당연한 결과였다. 일반적인 GUI 프로그램은 초당 수십 번 화면을 다시 그리는 것이 자연스럽지만, 악기는 다르다. 연주자가 버튼을 누르거나 노브를 돌리지 않는 동안에는 화면이 바뀔 이유가 거의 없다. 그렇다면 굳이 계속 프레임버퍼를 갱신할 필요도 없다.

그래서 Fluid Ardule의 UI 설계를 근본적으로 바꾸기로 했다.

이제 화면은 사용자 입력이 있을 때만 갱신한다. 버튼, 인코더, 메뉴 이동, 파라미터 변경과 같은 이벤트가 발생할 때만 TFT를 다시 그린다. CPU 온도나 Load와 같은 시스템 정보도 일정 주기로 갱신하지 않고, 필요할 때만 새로 읽어온다. 현재 예외는 실시간으로 변할 수 있는 MIDI 연결 상태 정도뿐이다.

설계를 변경하여 이벤트가 있을 때에만 화면을 갱신하도록 만들었더니 파이썬의 CPU 점유율이 13% 근처로 떨어졌다. 이는 엄청난 수준의 개선이다.

이러한 변경은 단순한 최적화가 아니다. Fluid Ardule의 설계 철학 자체를 바꾸는 일이다. 앞으로는 일반적인 데스크톱 애플리케이션이 아니라, 전원을 켜면 즉시 연주할 수 있는 전용 하드웨어 악기와 같은 동작을 목표로 하려고 한다.

이번 작업에서는 이와 함께 Media Player의 인터페이스도 다듬었고, 0바이트 yoshimi.config 파일이 시작 실패의 원인이 될 수 있다는 사실도 확인하여 복구 절차를 문서화했다. 또한 동일한 이벤트 기반 렌더링 정책을 앞으로 Combi 기능에도 적용하여, 다중 MIDI 처리에서도 안정성을 높여 나갈 계획이다.

새로운 기능을 하나 추가한 것은 아니다. 하지만 이번 변경은 지금까지의 개발 가운데 6월 17일의 ISR 적용과 더불어 가장 의미 있는 개선 중 하나였다고 생각한다. 화면을 덜 그리는 것이 오히려 더 좋은 악기를 만든다는 사실을 직접 확인했기 때문이다.