Miért rögzíti a képernyőfelvétel a rossz monitort (és hogyan javítottuk)

Íme egy hiba, amely csak akkor létezik, ha két monitorod van — ezért is élt csendben egy ideig. Az oldalsó kijelződön dolgozol, elindítasz egy GeekBye-felvételt, az meg az elsődleges monitorodat veszi fel. Azt, amelyiken a menüsáv van. Azt, amelyiket nem nézted.

Ugyanez a hiba, csendesebben és rosszabbul, azokat a képernyőképeket érintette, amelyeket a GeekBye kontextusként küld az AI-nak: megnyomod a képernyőkép-gyorsbillentyűt a második monitorodon, az AI meg az elsőről kap képet. Nincs semmilyen vizuális jel — az asszisztens egyszerűen a rossz képernyőről válaszol, te meg csak találgatod, miért van összezavarodva. A GeekBye v2.0.10 mindkettőt megjavította.

Két pipeline, egy lusta alapérték

A képernyő rögzítése a desktopon két külön kódútvonal, és mindkettő egymástól függetlenül az elsődleges kijelzőt választotta:

• A videófelvétel felsorolta az elérhető screen source-okat, és az elsőt vette — sources[0]. macOS-en ez gyakorlatilag mindig az elsődleges kijelző. Nincs picker, nincs logika arról, hogy valójában hol voltál. A saját kódunkban a komment szó szerint azt mondta: „auto-select first screen source."
• A képernyőképek a macOS screencapture parancsot használták a -m flag-gel. Annak a flag-nek pontosan egy jelentése van: csak az elsődleges kijelző. Beégetve.

Egyik útvonal sem tette fel soha a kérdést, amely számít: melyik képernyőn van a felhasználó?

Egy dolog, ami soha nem volt elromolva, és érdemes tisztázni, mert az emberek azt feltételezik, hogy volt: az azonos monitoron lévő macOS Spaces közötti váltás mindig működött. A rögzítés kijelző szinten történik — azt a Space-t kapja el, amelyik a kiválasztott kijelzőn látható. A hiba soha nem a Spaces-ről szólt. Mindig a rossz fizikai kijelző kiválasztásáról szólt.

A javítás, amely nyilvánvalónak tűnt — és rossz volt

A helyes jel könnyűnek tűnik: rögzítsd azt a kijelzőt, amelyen a felhasználó van. Az első implementációnk a GeekBye overlay ablakához horgonyzott — rögzítsd azt a kijelzőt, amelyen az overlay él.

A code review megölte, jogosan. A GeekBye overlay-e full-workarea ablakként jön létre az elsődleges kijelzőn, a (0,0) pozícióban. Csak akkor kerül át másik monitorra, ha fizikailag odahúzod a pirulát — a gyorsbillentyűk pedig, amelyek arrébb tolják, az elsődleges kijelző méreteire korlátozódnak, tehát egyáltalán nem tudják átvinni egy második monitorra. A rögzítés overlay-hez horgonyzása azt jelentette: minden felhasználónál, aki nem éppen áthúzta az overlay-t a munkaképernyőjére, a „javítás" pontosan visszaoldódott az elsődleges kijelzőre. Szinte senkinél sem javított volna — miközben egy egymonitoros dev gépen egy gyors teszten úgy nézett ki, mintha működne.

A helyes horgony a kurzor. Bárhol is van az egered, az az a kijelző, amelyen dolgozol — és ez minden rögzítésindítási módra helyes: egy gyorsbillentyű ott sül el, ahová mutatsz, a Record gomb megnyomása pedig definíció szerint arra a kijelzőre helyezi a kurzorodat. A végleges javítás egy kétsoros függvény: a kurzorhoz legközelebbi kijelző. A videó a capture source-át ahhoz a kijelző id-jéhez igazítja; a képernyőképek annak a kijelzőnek a bounds-át adják át a screencapture -R-nek (egy konkrét téglalap) a -m elsődleges-kijelző flag helyett.

Szándékosan a -R-t (egy explicit téglalap globális képernyő-koordinátákban) választottuk a -D (egy kijelző-index) helyett: az operációs rendszer kijelző-indexének nincs garantált megfelelése a framework kijelző-sorrendjével, így egy index egy második találgatós játék lenne. A kijelző tényleges bounds-ából származó téglalap egyértelmű — és a szállítás előtt egy valódi multi-monitoros rig-en ellenőriztük a flag viselkedését, beleértve az elsődlegestől balra elhelyezett kijelzők negatív koordinátáit is.

Miért ez egy jó tanulságos hiba

1. A „rögzítsd a képernyőt" elrejt egy döntést. Egyetlen kijelzőn nincs döntés, így a döntést soha nem tervezik meg — alapértékként adódik. A multi-monitor az, ahol minden implicit alapérték felszínre kerül.
2. A csendben-rossz rosszabb, mint a láthatóan-rossz. A videós hiba idegesítette az embereket. A képernyőkép-hiba az AI-t vezette félre, láthatatlanul. Amikor olyan funkciókat építesz, amelyek kontextussal táplálnak egy modellt, egy rossz bemenet magabiztosan rossz kimenetet produkál, sehol egy hibaüzenet. Ezek azok a hibák, amelyeket a legkeményebben érdemes vadászni.
3. Egy javítás, amely a te gépeden átmegy, mindenki máséin megbukhat. Az overlay-hez horgonyzott verzió működött egy egymonitoros teszten. A hiba egész lényege a több monitor — és a reviewer az ablak valódi pozíciójáról okoskodott, ahelyett hogy a zöld tesztnek hitt volna. A review nem egy gumibélyegző a működő kódon; egy második modell arról, hogy miért működik a kód.

A GeekBye v2.0.10 a kurzoralapú javítást szállítja mind a felvételhez, mind a képernyőképekhez. Ha több kijelzőt használsz, a rögzítés mostantól követ.

A sorozat szomszédos kiadásaihoz lásd, miért állítja le az AI-jegyzetelőd a felvételt a meeting kellős közepén (v2.0.9) és miért hallja félre az AI-átirat a szakkifejezéseket (v2.0.11). Ahhoz, hogyan viselkedik az overlay hívások közben, lásd hogyan maradj láthatatlan képernyőmegosztás közben.