Steven
Steven4 min czytania

Dlaczego nagrywanie ekranu przechwytuje niewłaściwy monitor (i jak to naprawiliśmy)

Na zestawie z dwoma monitorami GeekBye nagrywał i zrzucał obraz z ekranu głównego bez względu na to, na którym ekranie pracowałeś. Poprawka była jedną małą funkcją — ale jej pierwsza wersja była błędna, a code review wychwyciło dlaczego.

Nagrywanie ekranu
Wiele ekranów
Inżynieria
Wydania GeekBye
Dlaczego nagrywanie ekranu przechwytuje niewłaściwy monitor (i jak to naprawiliśmy)

Oto błąd, który istnieje tylko wtedy, gdy masz dwa monitory — dlatego przez jakiś czas żył cicho. Pracujesz na bocznym ekranie, uruchamiasz nagrywanie GeekBye, a ono nagrywa Twój monitor główny. Ten z paskiem menu. Ten, na który nie patrzyłeś.

Ta sama wada, cichsza i gorsza, dotknęła zrzuty ekranu, które GeekBye wysyła do AI jako kontekst: naciskasz skrót zrzutu na drugim monitorze, a AI dostaje obraz pierwszego. Nie ma żadnego wizualnego sygnału — asystent po prostu odpowiada na temat złego ekranu, a Ty zastanawiasz się, dlaczego jest zdezorientowany. GeekBye v2.0.10 naprawiło oba.

Dwa mechanizmy, jeden leniwy domyślny wybór

Przechwytywanie ekranu na pulpicie to dwie osobne ścieżki kodu i obie niezależnie wybrały ekran główny:

  • Nagrywanie wideo wyliczało dostępne źródła ekranu i brało pierwsze — sources[0]. Na macOS to praktycznie zawsze ekran główny. Bez selektora, bez żadnej logiki dotyczącej tego, gdzie faktycznie byłeś. Komentarz w naszym własnym kodzie mówił dosłownie "auto-select first screen source" (automatyczny wybór pierwszego źródła ekranu).
  • Zrzuty ekranu używały macOS-owej komendy screencapture z flagą -m. Ta flaga ma dokładnie jedno znaczenie: tylko ekran główny. Zaszyte na sztywno.

Żadna ze ścieżek nigdy nie zadała pytania, które ma znaczenie: na którym ekranie jest użytkownik?

Jedna rzecz, która nigdy nie była zepsuta, a warto ją wyjaśnić, bo ludzie zakładają inaczej: przełączanie między przestrzeniami (Spaces) macOS na tym samym monitorze zawsze działało. Przechwytywanie odbywa się na poziomie ekranu — chwyta to, co jest widoczne na wybranym ekranie. Błąd nigdy nie dotyczył przestrzeni. Zawsze chodziło o wybór złego fizycznego ekranu.

Poprawka, która wyglądała oczywiście — a była błędna

Właściwy sygnał wydaje się prosty: przechwyć ekran, na którym jest użytkownik. Nasza pierwsza implementacja zakotwiczyła się na oknie nakładki GeekBye — przechwytuj ten ekran, na którym żyje nakładka.

Code review słusznie ją zabiło. Nakładka GeekBye jest tworzona jako okno na pełen obszar roboczy na ekranie głównym, w pozycji (0,0). Przenosi się na inny monitor tylko wtedy, gdy fizycznie przeciągniesz tam jej pigułkę — a skróty klawiszowe, które ją przesuwają, przycinają się do wymiarów ekranu głównego, więc nie mogą przenieść jej na drugi monitor w ogóle. Zakotwiczenie przechwytywania na nakładce oznaczało: dla każdego użytkownika, który akurat nie przeciągnął nakładki na swój roboczy ekran, "poprawka" rozwiązywała się z powrotem do ekranu głównego. Nie naprawiłaby prawie nikogo — a przy szybkim teście na jednomonitorowej maszynie deweloperskiej wyglądałaby, jakby działała.

Właściwym punktem zaczepienia jest kursor. Gdziekolwiek jest Twoja mysz, tam jest ekran, na którym pracujesz — i jest to poprawne dla każdego sposobu rozpoczęcia przechwytywania: skrót klawiszowy wyzwala się tam, gdzie wskazujesz, a kliknięcie przycisku Nagrywaj z definicji stawia kursor na tym ekranie. Ostateczna poprawka to dwuwierszowa funkcja: ekran najbliższy kursorowi. Wideo dopasowuje swoje źródło przechwytywania do id tego ekranu; zrzuty przekazują granice tego ekranu do screencapture -R (konkretny prostokąt) zamiast flagi -m (tylko ekran główny).

Świadomie wybraliśmy -R (jawny prostokąt w globalnych współrzędnych ekranu) zamiast -D (indeks ekranu): indeks ekranu w systemie nie ma gwarantowanego związku z kolejnością ekranów we frameworku, więc indeks byłby drugą grą w zgadywanie. Prostokąt z rzeczywistych granic ekranu jest jednoznaczny — a zachowanie flagi zweryfikowaliśmy, łącznie z ujemnymi współrzędnymi dla ekranów umieszczonych na lewo od głównego, na prawdziwym zestawie wielomonitorowym przed wydaniem.

Dlaczego to dobry błąd dydaktyczny

  1. "Przechwyć ekran" ukrywa decyzję. Na jednym ekranie nie ma decyzji, więc decyzja nigdy nie zostaje zaprojektowana — zostaje domyślnie ustawiona. Wiele monitorów to miejsce, gdzie wychodzi na jaw każdy niejawny domyślny wybór.
  2. Ciche-złe jest gorsze niż widocznie-złe. Błąd wideo irytował ludzi. Błąd zrzutu wprowadzał w błąd AI, niewidzialnie. Gdy budujesz funkcje, które zasilają model kontekstem, złe wejście produkuje pewnie błędne wyjście bez żadnego błędu nigdzie. To właśnie te awarie warto tropić najzacieklej.
  3. Poprawka, która przechodzi na Twojej maszynie, może zawieść na każdej innej. Wersja zakotwiczona na nakładce działała w teście jednomonitorowym. Całym sensem tego błędu jest wiele monitorów — a recenzent zastanowił się nad rzeczywistą pozycją okna, zamiast ufać zielonemu testowi. Review to nie pieczątka na działającym kodzie; to drugi model tego, dlaczego kod działa.

GeekBye v2.0.10 dostarcza opartą na kursorze poprawkę zarówno dla nagrywania, jak i zrzutów. Jeśli używasz wielu ekranów, przechwytywanie teraz podąża za Tobą.

Sąsiednie wydania z tej serii znajdziesz w dlaczego Twój notatnik AI przerywa nagrywanie w trakcie spotkania (v2.0.9) oraz dlaczego transkrypcja AI przekręca terminy techniczne (v2.0.11). O tym, jak nakładka zachowuje się podczas połączeń, przeczytasz w jak pozostać niewidzialnym podczas udostępniania ekranu.