Steven
Steven5 min leestijd

Waarom schermopname het verkeerde beeldscherm vastlegt (en onze fix)

Op een opstelling met twee monitoren nam en screenshotte GeekBye altijd het primaire scherm, ongeacht op welk scherm je werkte. De fix was één kleine functie — maar de eerste versie was fout, en de code review vond uit waarom.

Schermopname
Multi-Display
Engineering
GeekBye Releases
Waarom schermopname het verkeerde beeldscherm vastlegt (en onze fix)

Dit is een bug die alleen bestaat als je twee monitoren hebt — en daarom leefde hij een tijdje in stilte. Je werkt op je zijscherm, start een GeekBye-opname, en die neemt je primaire monitor op. De monitor met de menubalk. De monitor waar je niet naar keek.

Hetzelfde defect, stiller en erger, trof de screenshots die GeekBye als context naar de AI stuurt: druk op je tweede monitor op de screenshot-sneltoets, en de AI krijgt een plaatje van je eerste. Er is geen visueel teken — de assistent antwoordt gewoon over het verkeerde scherm en jij vraagt je af waarom hij in de war is. GeekBye v2.0.10 verhielp beide.

Twee pipelines, één luie default

Schermcapture op de desktop bestaat uit twee losse codepaden, en beide hadden onafhankelijk het primaire scherm gekozen:

  • Video-opname somde de beschikbare schermbronnen op en nam de eerste — sources[0]. Op macOS is dat feitelijk altijd het hoofdscherm. Geen picker, geen logica over waar je eigenlijk was. Het commentaar in onze eigen code zei letterlijk "auto-select first screen source."
  • Screenshots gebruikten het macOS-commando screencapture met de vlag -m. Die vlag heeft precies één betekenis: main display only. Hardcoded.

Geen van beide paden stelde ooit de vraag die telt: op welk scherm zit de gebruiker?

Eén ding dat nooit kapot was, het opheldering waard omdat mensen aannemen van wel: schakelen tussen macOS Spaces op dezelfde monitor werkte altijd. Capture gebeurt op displayniveau — het pakt welke Space er ook zichtbaar is op het gekozen display. De bug ging nooit over Spaces. Hij ging altijd over het kiezen van het verkeerde fysieke display.

De fix die voor de hand leek te liggen — en fout was

Het juiste signaal lijkt makkelijk: leg het scherm vast waar de gebruiker op zit. Onze eerste implementatie verankerde op GeekBye's overlayvenster — leg welk display de overlay ook op leeft vast.

De code review maakte het af, en terecht. GeekBye's overlay wordt aangemaakt als een full-workarea-venster op het primaire scherm, op positie (0,0). Het verplaatst alleen naar een andere monitor als je de pil er fysiek naartoe sleept — en de sneltoetsen die het rondduwen klemmen op de afmetingen van het primaire scherm, dus die kunnen het helemaal niet naar een tweede monitor verplaatsen. Capture verankeren op de overlay betekende: voor elke gebruiker die de overlay niet toevallig op zijn werkscherm had gesleept, viel de "fix" gewoon weer terug op het primaire scherm. Het zou zo goed als niemand hebben geholpen — terwijl het, in een snelle test op een dev-machine met één monitor, leek te werken.

Het juiste anker is de cursor. Waar je muis ook is, dat is het scherm waarop je werkt — en het klopt voor elke manier waarop een capture start: een sneltoets vuurt waar je wijst, en klikken op de Opnemen-knop zet je cursor per definitie op dat scherm. De uiteindelijke fix is een functie van twee regels: het scherm het dichtst bij de cursor. Video matcht zijn capture-bron aan het id van dat scherm; screenshots geven de grenzen van dat scherm door aan screencapture -R (een specifieke rechthoek) in plaats van de -m-vlag voor het hoofdscherm.

We kozen bewust voor -R (een expliciete rechthoek in globale schermcoördinaten) boven -D (een display-index): de display-index van het OS heeft geen gegarandeerde correspondentie met de displayvolgorde van het framework, dus een index zou een tweede raadspel zijn. Een rechthoek uit de werkelijke schermgrenzen is ondubbelzinnig — en we verifieerden het gedrag van de vlag, inclusief negatieve coördinaten voor schermen die links van het primaire staan, op een echte multi-monitoropstelling voordat we het uitleverden.

Waarom dit een goede leerbug is

  1. "Leg het scherm vast" verbergt een beslissing. Op één display is er geen beslissing, dus de beslissing wordt nooit ontworpen — hij wordt gedefault. Multi-monitor is waar elke impliciete default naar boven komt.
  2. Stil-fout is erger dan zichtbaar-fout. De videobug irriteerde mensen. De screenshotbug misleidde de AI, onzichtbaar. Als je features bouwt die context naar een model voeden, produceert een verkeerde input een zelfverzekerd verkeerde output zonder ergens een foutmelding. Dat zijn de failures die het hardst nagejaagd moeten worden.
  3. Een fix die op jouw machine slaagt kan op ieders andere falen. De op de overlay verankerde versie werkte in een test met één monitor. Het hele punt van de bug is meerdere monitoren — en de reviewer redeneerde over de echte positie van het venster in plaats van de groene test te vertrouwen. Review is geen stempel op werkende code; het is een tweede model van waarom de code werkt.

GeekBye v2.0.10 levert de cursor-gebaseerde fix voor zowel opname als screenshots. Draai je meerdere schermen, dan volgt de capture je nu.

Voor de aangrenzende releases in deze serie, zie waarom je AI-notulist midden in een meeting stopt met opnemen (v2.0.9) en waarom AI-transcriptie technische termen verkeerd verstaat (v2.0.11). Voor hoe de overlay zich gedraagt tijdens gesprekken, zie hoe je onzichtbaar blijft tijdens schermdelen.