Steven
Steven4 min lukuaika

Miksi näyttötallennus kaappaa väärän näytön (ja miten korjasimme sen)

Kahden näytön kokoonpanossa GeekBye tallensi ja kuvakaappasi ensisijaisen näytön riippumatta siitä, millä ruudulla työskentelit. Korjaus oli yksi pieni funktio — mutta sen ensimmäinen versio oli väärä, ja koodikatselmointi nappasi kiinni, miksi.

Näyttötallennus
Usea näyttö
Ohjelmistokehitys
GeekBye-julkaisut
Miksi näyttötallennus kaappaa väärän näytön (ja miten korjasimme sen)

Tässä bugi, joka on olemassa vain jos omistat kaksi näyttöä — juuri siksi se eli hiljaa jonkin aikaa. Työskentelet sivunäytölläsi, käynnistät GeekBye-tallennuksen, ja se tallentaa ensisijaisen näyttösi. Sen, jossa on valikkopalkki. Sen, jota et katsonut.

Sama vika, hiljaisempana ja pahempana, osui kuvakaappauksiin, jotka GeekBye lähettää AI:lle kontekstiksi: paina kuvakaappauksen pikanäppäintä toisella näytölläsi, ja AI saa kuvan ensimmäisestä. Mitään näkyvää vihjettä ei ole — avustaja vain vastaa väärästä ruudusta ja sinä jäät ihmettelemään, miksi se on hämmentynyt. GeekBye v2.0.10 korjasi molemmat.

Kaksi putkea, yksi laiska oletus

Ruudun kaappaus työpöydällä on kaksi erillistä koodipolkua, ja molemmat olivat toisistaan riippumatta valinneet ensisijaisen näytön:

  • Videotallennus luetteli saatavilla olevat näyttölähteet ja otti ensimmäisen — sources[0]. macOS:ssä se on käytännössä aina ensisijainen näyttö. Ei valitsinta, ei mitään logiikkaa siitä, missä oikeasti olit. Kommentti omassa koodissamme sanoi kirjaimellisesti "auto-select first screen source."
  • Kuvakaappaukset käyttivät macOS:n screencapture-komentoa -m-lipulla. Sillä lipulla on täsmälleen yksi merkitys: vain ensisijainen näyttö. Kovakoodattu.

Kumpikaan polku ei koskaan kysynyt sitä kysymystä, jolla on väliä: millä ruudulla käyttäjä on?

Yksi asia, joka ei koskaan ollut rikki, ja jonka kannattaa selventää, koska ihmiset olettavat sen olleen: macOS:n Spaces-työtilojen välillä vaihtaminen samalla näytöllä toimi aina. Kaappaus tapahtuu näyttötasolla — se sieppaa minkä tahansa Space-työtilan, joka valitulla näytöllä näkyy. Bugi ei koskaan liittynyt Spaces-työtiloihin. Se liittyi aina väärän fyysisen näytön valitsemiseen.

Korjaus, joka näytti itsestäänselvältä — ja oli väärä

Oikea signaali vaikuttaa helpolta: kaappaa se näyttö, jolla käyttäjä on. Ensimmäinen toteutuksemme ankkuroitui GeekByen overlay-ikkunaan — kaappaa se näyttö, jolla overlay elää.

Koodikatselmointi tappoi sen, aivan oikein. GeekByen overlay luodaan täyden työalueen ikkunana ensisijaiselle näytölle, sijaintiin (0,0). Se siirtyy toiselle näytölle vain, jos raahaat sen pillerin sinne fyysisesti — ja pikanäppäimet, jotka sitä nykivät, kiinnittyvät ensisijaisen näytön mittoihin, joten ne eivät voi siirtää sitä toiselle näytölle lainkaan. Kaappauksen ankkurointi overlayhin tarkoitti: jokaiselle käyttäjälle, joka ei sattunut raahaamaan overlayta työruudulleen, "korjaus" ratkesi suoraan takaisin ensisijaiselle näytölle. Se ei olisi korjannut lähes ketään — samalla näyttäen yhden näytön kehityskoneen nopeassa testissä siltä, että toimii.

Oikea ankkuri on kursori. Missä ikinä hiiresi on, se on se näyttö, jolla työskentelet — ja se on oikein jokaisella tavalla, jolla kaappaus alkaa: pikanäppäin laukeaa siellä, minne osoitat, ja Record-painikkeen klikkaaminen vie kursorisi sille näytölle jo määritelmän mukaan. Lopullinen korjaus on kaksirivinen funktio: kursoria lähin näyttö. Video sovittaa kaappauslähteensä sen näytön id:hen; kuvakaappaukset välittävät sen näytön rajat komennolle screencapture -R (tietty suorakulmio) -m-ensisijaisnäyttölipun sijaan.

Valitsimme tarkoituksella -R:n (selkeä suorakulmio globaaleissa näyttökoordinaateissa) -D:n (näytön indeksi) sijaan: käyttöjärjestelmän näyttöindeksillä ei ole taattua vastaavuutta kehyksen näyttöjärjestykseen, joten indeksi olisi toinen arvausleikki. Suorakulmio todellisista näytön rajoista on yksiselitteinen — ja varmistimme lipun käyttäytymisen, mukaan lukien negatiiviset koordinaatit ensisijaisen näytön vasemmalle puolelle sijoitetuille näytöille, oikealla usean näytön kokoonpanolla ennen julkaisua.

Miksi tämä on hyvä opettava bugi

  1. "Kaappaa ruutu" kätkee päätöksen. Yhdellä näytöllä ei ole päätöstä, joten päätöstä ei koskaan suunnitella — se jää oletukseksi. Usea näyttö on paikka, jossa jokainen epäsuora oletus nousee pintaan.
  2. Hiljaa-väärin on pahempaa kuin näkyvästi-väärin. Videobugi ärsytti ihmisiä. Kuvakaappausbugi harhautti AI:ta, näkymättömästi. Kun rakennat ominaisuuksia, jotka syöttävät kontekstia mallille, väärä syöte tuottaa itsevarmasti väärän tuloksen ilman virhettä missään. Juuri niitä vikoja kannattaa metsästää kovimmin.
  3. Korjaus, joka menee läpi sinun koneellasi, voi kaatua kaikkien muiden koneilla. Overlayhin ankkuroitu versio toimi yhden näytön testissä. Koko bugin ydin on useat näytöt — ja katselmoija päätteli ikkunan todellisesta sijainnista sen sijaan, että olisi luottanut vihreään testiin. Katselmointi ei ole leima toimivalle koodille; se on toinen malli siitä, miksi koodi toimii.

GeekBye v2.0.10 tuo kursoripohjaisen korjauksen sekä tallennukselle että kuvakaappauksille. Jos käytät useaa näyttöä, kaappaus seuraa nyt sinua.

Sarjan naapurijulkaisut löydät täältä: miksi AI-muistiinpanotyökalusi lopettaa tallennuksen kesken kokouksen (v2.0.9) ja miksi AI-transkriptio kuulee tekniset termit väärin (v2.0.11). Siitä, miten overlay käyttäytyy puheluiden aikana, lue miten pysyt näkymättömänä näytönjaon aikana.