소리꽃 KeyBloom TIL 2
파티클을 최대로 올렸을 때 버벅이는 느낌이 있어서, 고치기 전에 재는 도구부터 만들었다.
재고 나서 정하기
최적화 전에 재 보면 안 해도 되는 경우가 있다
파티클을 최대로 올리면 버벅이는 것 같았다. 전날 그리는 방식을 스프라이트(미리 그려 둔 그림 조각)로 바꿔서 나아지긴 했는데, 더 손봐야 하는지 감이 안 왔다.
그래서 FPS(초당 몇 장을 그리는가)와 한 프레임에 쓰는 시간, 파티클 개수를 화면에 띄우는 도구를 먼저 만들었다. 재 보니 여유가 꽤 있었다. 더 할 일이 없다는 결론이 나왔다.
이게 도구를 만든 값이었다. 재지 않았으면 “버벅이는 것 같다”는 느낌으로 며칠을 더 썼을 것이다. 성능 작업에서 제일 비싼 건 느린 코드가 아니라 안 해도 되는 최적화다. 재는 데 드는 시간은 대개 그보다 훨씬 짧다.
두 숫자의 차이가 어느 자원이 병목인지 말해 준다
느린 게 어디서 오는지 알고 싶었다. 크게 둘이다. 우리 JavaScript 계산이 오래 걸리는 CPU 쪽과, 화면에 칠할 픽셀이 너무 많은 GPU 쪽.
이걸 가르는 방법이 있었다. 우리 코드가 실제로 붙잡은 시간과, 한 프레임이 완성되기까지의 전체 시간을 따로 재는 것이다. “그려라”라는 명령을 던지는 데까지는 우리 시간에 잡히지만 실제로 픽셀이 칠해지는 일(래스터화)은 그 뒤에 GPU가 따로 한다. 그래서 전체 시간에서 우리 시간을 빼면 그 나머지가 GPU 몫이다.
우리 시간이 한 프레임 예산(60fps면 16.7밀리초)을 다 쓰고 있으면 계산을 줄여야 하고, 우리 시간은 여유로운데 전체가 느리면 그리는 양을 줄여야 한다. 손댈 곳이 완전히 다르다.
“느리다”는 하나가 아니라 여러 종류다. 어느 종류인지를 먼저 가르지 않으면 엉뚱한 데를 고치게 된다. 그리고 그걸 가르는 방법은 대개 숫자 두 개를 따로 재서 비교하는 것이다.
미루기와 나누기
미루기를 넣으면 강제 실행이 짝으로 따라온다
색 슬라이더를 끌 때마다 화면이 튀었다. 색이 바뀔 때마다 스프라이트를 전부 다시 굽고 있었는데, 한 번에 수십 밀리초가 걸리는 일이라 드래그하는 내내 그게 반복됐다.
값이 바뀌는 동안은 미뤄 두고 잠깐 멈춘 뒤에 한 번만 굽게 바꿨다. 이렇게 연속 입력을 뒤로 미뤘다가 한 번만 실행하는 걸 디바운스라고 한다.
그러자 새 문제가 생길 수 있었다. 미뤄 둔 상태에서 녹화를 시작하면 영상 첫 부분이 옛 설정으로 찍힌다. 그래서 녹화 직전에 미뤄 둔 것을 강제로 실행하게 했다(플러시).
무언가를 미루는 장치를 넣으면 “지금 당장 정확해야 하는 순간”이 반드시 어딘가에 있다. 디바운스와 플러시는 짝이고, 짝을 안 만들면 미룬 것이 결과물에 그대로 남는다. 저장·전송·인쇄·녹화처럼 확정되는 지점을 찾아 거기에 붙여야 한다.
즉시 꺼질 것과 서서히 꺼질 것을 나눈다
건반을 떼면 빛이 뚝 꺼져서 여운을 넣고 싶었다.
전부 서서히 사라지게 하니 이상했다. 건반 색이 천천히 빠지면 누르지도 않은 건반이 눌린 것처럼 보인다. 그래서 나눴다. 건반 색과 표면 반짝임(sheen)은 뗀 즉시 꺼지고, 위로 뻗는 글로우만 천천히 잦아든다.
하나의 사건에 딸린 표현이 여럿일 때 그것들이 같은 속도로 사라져야 할 이유는 없다. 무엇이 상태를 나타내고 무엇이 흔적을 나타내는지를 갈라야 한다. 상태는 즉시, 흔적은 천천히.
요약
- 최적화 전에 재 본다 — 제일 비싼 건 느린 코드가 아니라 안 해도 되는 최적화다
- “느리다”는 여러 종류다. CPU 시간과 전체 프레임 시간을 따로 재면 종류가 갈린다
- 디바운스를 넣으면 플러시가 짝으로 따라온다. 확정되는 지점에 붙인다
- 한 사건의 표현들이 같은 속도로 사라질 이유는 없다 — 상태는 즉시, 흔적은 천천히