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.

Aiheeseen liittyvät artikkelit

Hiljaisuus oli kantava
Steven
Steven6 min lukuaika

Hiljaisuus oli kantava

GeekBye v1:n kaksi viimeistä julkaisua kertovat samasta epämukavasta totuudesta: reaaliaikainen transkriptio oikean verkon yli ei ole häviötöntä, ja rehellinen liike on lakata teeskentelemästä että se on. v1.8.20 säilytti jokaisesta äänipalasta kopion levyllä ennen kuin pudotti sen uudelleenyhdistämisen aikana, ja alkoi merkitä transkription aukot ääneen. v1.9.0 lakkasi lähettämästä hiljaisuutta kaistanleveyden säästämiseksi — ja huomasi, että hiljaisuus oli juuri se signaali, jolla transkriboija tiesi lauseen päättyneen. Kaksi julkaisua asioiden pois heittämisen hinnasta.

Ohjelmistokehitys
Audio
Luotettavuus
Kolme verbiä, jotka pitävät Web Audion elossa
Steven
Steven7 min lukuaika

Kolme verbiä, jotka pitävät Web Audion elossa

Kaksi GeekBye-julkaisua, kahden kuukauden välein ja kahdessa eri tiedostossa, opettivat ääni-koodillemme saman opetuksen vastakkaisista päistä: lakkaa kohtelemasta selaimen AudioContextia kertakäyttöisenä. Yksi julkaisu oppi kutsumaan resume() kontekstille, jonka macOS oli hiljaa keskeyttänyt kesken tallennuksen; toinen oppi kutsumaan suspend() eikä close(), niin että peräkkäiset istunnot lakkaavat törmäämästä Chromiumin noin-kuuden-kontekstin kattoon. Resume, suspend, close — siinä on koko juoni.

Ohjelmistokehitys
Audio
Desktop
Puhelun erottaminen avoimesta sovelluksesta
Steven
Steven7 min lukuaika

Puhelun erottaminen avoimesta sovelluksesta

GeekBye voi huomata, että olet liittynyt videokokoukseen, ja tarjoutua tallentamaan sen. Tunnistus osoittautuu helpommaksi puoliskoksi — Swift-binääri, joka lukee ikkunoiden otsikoita joka kymmenes sekunti. Vaikea puolisko on tarkkuus: olla laukeamatta kun Zoom on vain auki, olla tarjoamatta kokousta jota jo tallennat, ja olla mykistämättä mikrofonia puhelussa jossa oikeasti olet. Kolme julkaisua, ja jokainen niistä on vartija jonka oli opittava olemaan kukistamatta itseään.

Ohjelmistokehitys
macOS
Desktop