Steven
Steven5 min citire

De ce înregistrarea ecranului capturează monitorul greșit (și cum am rezolvat)

Pe un setup cu două monitoare, GeekBye înregistra și făcea capturi de pe ecranul principal indiferent pe care lucrai. Fixul a fost o singură funcție mică — dar prima ei versiune era greșită, iar code review-ul a prins de ce.

Înregistrare ecran
Multi-Display
Inginerie
Lansări GeekBye
De ce înregistrarea ecranului capturează monitorul greșit (și cum am rezolvat)

Iată un bug care există doar dacă ai două monitoare — de aceea a trăit liniștit o vreme. Lucrezi pe display-ul lateral, pornești o înregistrare GeekBye, iar ea îți înregistrează monitorul principal. Cel cu bara de meniu. Cel la care nu te uitai.

Același defect, mai tăcut și mai grav, lovea capturile pe care GeekBye le trimite AI-ului drept context: apeși scurtătura de captură pe al doilea monitor, iar AI-ul primește o poză cu primul. Nu există niciun semn vizual — asistentul pur și simplu răspunde despre ecranul greșit, iar tu rămâi întrebându-te de ce e confuz. GeekBye v2.0.10 le-a rezolvat pe ambele.

Două pipeline-uri, un default leneș

Captura de ecran pe desktop înseamnă două căi de cod separate, iar ambele aleseseră independent display-ul principal:

  • Înregistrarea video enumera sursele de ecran disponibile și o lua pe prima — sources[0]. Pe macOS asta e practic mereu display-ul principal. Fără picker, fără vreo logică despre unde te aflai de fapt. Comentariul din propriul nostru cod spunea literalmente „auto-select first screen source."
  • Capturile de ecran foloseau comanda macOS screencapture cu flag-ul -m. Acel flag are exact un singur înțeles: doar display-ul principal. Hardcodat.

Nicio cale nu punea vreodată întrebarea care contează: pe ce ecran e utilizatorul?

Un lucru care nu a fost niciodată stricat, de clarificat pentru că lumea presupune că a fost: comutarea între Spaces pe același monitor a funcționat mereu. Captura se întâmplă la nivel de display — prinde orice Space e vizibil pe display-ul ales. Bug-ul nu a fost niciodată despre Spaces. A fost mereu despre alegerea display-ului fizic greșit.

Fixul care părea evident — și era greșit

Semnalul corect pare ușor: capturează display-ul pe care e utilizatorul. Prima noastră implementare s-a ancorat pe fereastra de overlay a GeekBye — capturează orice display pe care stă overlay-ul.

Code review-ul l-a ucis, pe bună dreptate. Overlay-ul GeekBye e creat ca fereastră de tip full-workarea pe display-ul principal, la poziția (0,0). Se mută pe alt monitor doar dacă îi tragi fizic pilula acolo — iar scurtăturile de tastatură care îl împing în jur se limitează la dimensiunile display-ului principal, deci nu-l pot muta deloc pe al doilea monitor. Ancorarea capturii pe overlay însemna: pentru fiecare utilizator care nu s-a nimerit să tragă overlay-ul pe ecranul lui de lucru, „fixul" se rezolva înapoi exact pe display-ul principal. Nu ar fi rezolvat aproape pentru nimeni — arătând totuși, într-un test rapid pe o mașină de dezvoltare cu un singur monitor, de parcă ar fi mers.

Ancora corectă e cursorul. Oriunde e mouse-ul tău, acela e display-ul pe care lucrezi — și e corect pentru fiecare mod în care pornește o captură: o scurtătură de tastatură se declanșează acolo unde arăți, iar apăsarea butonului Record îți pune cursorul pe acel display prin definiție. Fixul final e o funcție de două linii: display-ul cel mai apropiat de cursor. Video-ul își potrivește sursa de captură la id-ul acelui display; capturile trec bounds-urile acelui display către screencapture -R (un dreptunghi specific) în loc de flag-ul -m pentru display-ul principal.

Am ales -R (un dreptunghi explicit în coordonate globale de ecran) în locul lui -D (un index de display) în mod deliberat: index-ul de display al sistemului de operare nu are o corespondență garantată cu ordonarea display-urilor din framework, așa că un index ar fi un al doilea joc de ghicit. Un dreptunghi din bounds-urile reale ale display-ului e neambiguu — și am verificat comportamentul flag-ului, inclusiv coordonatele negative pentru display-uri poziționate în stânga celui principal, pe un rig real multi-monitor înainte de livrare.

De ce ăsta e un bug bun de învățat

  1. „Capturează ecranul" ascunde o decizie. Pe un singur display nu există decizie, deci decizia nu ajunge să fie proiectată — ajunge să fie lăsată pe default. Multi-monitorul e locul unde iese la suprafață fiecare default implicit.
  2. Greșit-în-tăcere e mai rău decât greșit-vizibil. Bug-ul video enerva oamenii. Bug-ul de captură inducea AI-ul în eroare, invizibil. Când construiești funcții care alimentează context într-un model, un input greșit produce un output încrezător greșit fără nicio eroare pe undeva. Astea sunt eșecurile care merită vânate cel mai tare.
  3. Un fix care trece pe mașina ta poate pica pe a tuturor celorlalți. Versiunea ancorată pe overlay a mers într-un test cu un singur monitor. Tot rostul bug-ului sunt monitoarele multiple — iar recenzorul a raționat despre poziția reală a ferestrei în loc să se încreadă în testul verde. Review-ul nu e o ștampilă de aprobare pe cod care merge; e un al doilea model al motivului pentru care codul merge.

GeekBye v2.0.10 livrează fixul bazat pe cursor atât pentru înregistrare, cât și pentru capturi. Dacă rulezi mai multe display-uri, captura te urmează acum.

Pentru lansările vecine din această serie, vezi de ce notetaker-ul tău AI oprește înregistrarea în mijlocul ședinței (v2.0.9) și de ce transcrierea AI înțelege greșit termenii tehnici (v2.0.11). Pentru cum se comportă overlay-ul în timpul apelurilor, vezi cum să rămâi invizibil în timpul partajării ecranului.