찍지 않기로 한 스크린샷

화면을 1초마다 기록한다고 하면 저장 공간 문제처럼 들립니다. 하지만 실제로는 ‘똑같음’의 문제입니다. 대부분의 1초는 바로 앞의 1초와 똑같아 보이고, 그런 장면들로 채워진 기록은 더 작은 기록보다 오히려 나쁩니다. 검색은 느려지고, 스크롤은 길어지고, 정말 원했던 순간은 그 속에 묻혀 버립니다.

그래서 LockTime은 무엇이든 보관하기 전에 먼저 화면이 조금이라도 바뀌었는지 묻습니다. 비교는 디스플레이를 192×192 회색조로 축소한 이미지, 즉 36,864개의 샘플을 대상으로 하며, 허용 오차는 두 단계입니다. 그래서 압축 노이즈는 변화로 치지 않지만, 다시 그려진 윈도우는 변화로 봅니다.

임곗값이 통하지 않는 이유

가장 먼저 떠오르는 규칙은 크기입니다. 샘플이 N개보다 많이 바뀌면 프레임을 보관하는 것이죠. 그래서 가만히 있는 데스크탑에서 실제로 무엇이 얼마나 움직이는지 측정해 보았습니다.

• 포인터를 화면 가로질러 움직이기: 샘플 4개.
• 메뉴 막대 시계가 1분 넘어가기: 샘플 7개.
• 문서에 단어 하나 입력하기: 샘플 23개.

36,864개 중에서 말입니다. 시계를 무시하려면 N이 7보다 커야 하고, 깜박이는 커서와 시계와 진행 표시기를 한꺼번에 무시하려면 더 커야 합니다. 그런데 방금 입력한 문장은 23입니다. 노이즈를 버리도록 맞춘 임곗값은 작업도 함께 버립니다. 둘의 크기가 같기 때문입니다.

대신 깜박임을 봅니다

기본 규칙은 얼마나 움직였는지가 아니라 어디가 움직였는지를 봅니다. LockTime은 화면에서 가만히 있지 못하는 칸, 즉 삽입 포인터, 진행 표시기, 움직이는 축소판 같은 곳을 학습해 더 이상 세지 않습니다. 서로 다른 세 번의 확인에서 움직인 칸은 원래 늘 움직이는 칸으로 간주되며, 그때부터는 화면의 나머지 부분만 캡처를 일으킬 수 있습니다.

이 학습에는 상한이 있습니다. 움직인 칸이 최대 12개인 확인에서만 LockTime이 무언가를 배웁니다. 페이지를 넘기거나, 윈도우를 전환하거나, 문서를 스크롤하면 수천 개의 칸이 한꺼번에 움직이는데, 그런 확인에서는 아무것도 배우지 않습니다. 따라서 실제 변화 때문에 앱이 화면 전체를 노이즈라고 믿게 되는 일은 결코 없습니다.

중요한 의미에서 이것은 손실이 없는 방식입니다. 사용자가 한 일은 하나도 빠지지 않습니다. 한 페이지를 읽으며 보낸 몇 분은 스크린샷 60장이 아니라 1장으로 남습니다.

직접 바꿀 수 있는 것

설정에는 세 가지 모드가 있습니다. 모든 변화는 샘플 하나만 움직여도 프레임을 보관합니다. 저절로 움직이는 것 무시는 위에서 설명한 기본값입니다. 뚜렷한 변화만은 화면의 상당 부분이 달라질 때까지 기다리며, 듬성듬성한 기록을 원하는 사람을 위한 모드입니다.

그 밖에도 1초부터 10분까지 정할 수 있는 간격과, 앱을 전환할 때 캡처하는 스위치가 있어 3초만 들른 윈도우도 흔적을 남깁니다.