ทำไมการบันทึกหน้าจอถึงจับมอนิเตอร์ผิดตัว (และวิธีที่เราแก้)

นี่คือบั๊กที่มีอยู่ก็ต่อเมื่อคุณมีสองจอเท่านั้น — เพราะอย่างนั้นมันจึงอยู่เงียบๆ มาได้พักหนึ่ง คุณทำงานอยู่บนจอด้านข้าง เริ่มการบันทึกด้วย GeekBye แล้วมันดันบันทึกจอหลักของคุณ จอที่มีเมนูบาร์ จอที่คุณไม่ได้มองอยู่

ข้อบกพร่องเดียวกัน เงียบกว่าและร้ายกว่า เล่นงานภาพแคปหน้าจอที่ GeekBye ส่งให้ AI เป็นบริบทด้วย: กด shortcut แคปหน้าจอบนมอนิเตอร์ตัวที่สองของคุณ แล้ว AI กลับได้รูปของจอตัวแรก ไม่มีร่องรอยให้เห็นเลย — ผู้ช่วยก็แค่ตอบเรื่องหน้าจอผิดตัว ส่วนคุณก็ได้แต่งงว่าทำไมมันถึงสับสน GeekBye v2.0.10 แก้ทั้งคู่แล้ว

สองไปป์ไลน์ กับค่าเริ่มต้นขี้เกียจตัวเดียว

การจับภาพหน้าจอบนเดสก์ท็อปเป็นเส้นทางโค้ดสองเส้นแยกจากกัน และทั้งคู่ต่างเลือกจอหลักโดยไม่ได้นัดหมายกัน:

• การบันทึกวิดีโอ ไล่ดู screen source ที่มีอยู่แล้วหยิบตัวแรก — sources[0] บน macOS นั่นแทบจะเป็นจอหลักเสมอ ไม่มีตัวเลือกให้เลือก ไม่มีตรรกะว่าจริงๆ แล้วคุณอยู่ตรงไหน คอมเมนต์ในโค้ดของเราเองเขียนไว้ตรงตัวเลยว่า "auto-select first screen source."
• ภาพแคปหน้าจอ ใช้คำสั่ง screencapture ของ macOS พร้อมแฟล็ก -m แฟล็กนี้มีความหมายเดียวเป๊ะๆ: main display only (จอหลักเท่านั้น) ฮาร์ดโค้ดไว้เลย

ทั้งสองเส้นทางไม่เคยถามคำถามที่สำคัญ: ผู้ใช้อยู่บนจอไหน?

มีสิ่งหนึ่งที่ไม่เคยพังเลย ขอเคลียร์ไว้เพราะคนมักเข้าใจว่ามันพัง: การสลับ macOS Spaces บนจอเดียวกันทำงานถูกต้องมาตลอด การจับภาพเกิดที่ระดับ display — มันจับ Space ใดก็ตามที่แสดงอยู่บนจอที่ถูกเลือก บั๊กนี้ไม่เคยเกี่ยวกับ Spaces มันเกี่ยวกับการเลือกจอกายภาพผิดตัวมาตั้งแต่ต้น

การแก้ที่ดูชัดเจน — และผิด

สัญญาณที่ถูกต้องดูเหมือนจะง่าย: จับจอที่ผู้ใช้อยู่ การ implement ครั้งแรกของเราไปยึดหน้าต่าง overlay ของ GeekBye — จับจอไหนก็ตามที่ overlay อาศัยอยู่

Code review ฆ่ามันทิ้ง ซึ่งถูกต้องแล้ว overlay ของ GeekBye ถูกสร้างเป็นหน้าต่างเต็ม work-area บนจอหลัก ที่ตำแหน่ง (0,0) มันจะย้ายไปจออื่นก็ต่อเมื่อคุณลากตัว pill ของมันไปที่นั่นด้วยมือเท่านั้น — และ keyboard shortcut ที่ใช้ขยับมันจะถูก clamp ไว้ตามขนาดของจอหลัก มันจึงย้ายไปจอที่สองไม่ได้เลย การยึดการจับภาพไว้กับ overlay จึงหมายความว่า: สำหรับผู้ใช้ทุกคนที่ไม่ได้บังเอิญลาก overlay ไปไว้บนจอที่ตัวเองทำงาน "การแก้" นี้ก็ย้อนกลับตรงไปที่จอหลักทันที มันแทบไม่แก้ให้ใครเลย — ทั้งที่ตอนเทสต์เร็วๆ บนเครื่องพัฒนาจอเดียว มันดูเหมือนใช้งานได้

จุดยึดที่ถูกต้องคือเคอร์เซอร์ เมาส์อยู่ตรงไหน นั่นแหละคือจอที่คุณกำลังทำงานอยู่ — และมันถูกต้องกับทุกวิธีที่การจับภาพเริ่มต้น: keyboard shortcut ยิงตรงจุดที่คุณชี้อยู่ และการคลิกปุ่ม Record ก็ทำให้เคอร์เซอร์ของคุณอยู่บนจอนั้นโดยนิยาม การแก้สุดท้ายคือฟังก์ชันสองบรรทัด: จอที่อยู่ใกล้เคอร์เซอร์ที่สุด วิดีโอจับคู่ capture source ของมันเข้ากับ id ของจอนั้น; ภาพแคปส่งขอบเขตของจอนั้นให้ screencapture -R (สี่เหลี่ยมเฉพาะ) แทนที่จะเป็นแฟล็ก -m แบบจอหลัก

เราเลือก -R (สี่เหลี่ยมชัดเจนในพิกัดหน้าจอแบบ global) แทน -D (display index) โดยตั้งใจ: index ของ display ระดับ OS ไม่มีอะไรรับประกันว่าจะตรงกับลำดับ display ของ framework ดังนั้นการใช้ index ก็จะเป็นการเดาอีกรอบ ส่วนสี่เหลี่ยมที่มาจากขอบเขตจอจริงนั้นไม่มีอะไรกำกวม — และเราได้ตรวจสอบพฤติกรรมของแฟล็กนี้แล้ว รวมถึงพิกัดติดลบสำหรับจอที่วางอยู่ทางซ้ายของจอหลัก บนเครื่องหลายจอจริงก่อนปล่อยออกไป

ทำไมบั๊กนี้ถึงเป็นบั๊กสอนใจที่ดี

1. "จับภาพหน้าจอ" ซ่อนการตัดสินใจไว้อันหนึ่ง บนจอเดียวไม่มีการตัดสินใจ การตัดสินใจนั้นจึงไม่เคยถูกออกแบบ — มันถูกปล่อยให้เป็นค่าดีฟอลต์แทน หลายจอคือที่ที่ดีฟอลต์โดยปริยายทุกอันโผล่ขึ้นมา
2. ผิดแบบเงียบๆ ร้ายกว่าผิดแบบเห็นชัด บั๊กวิดีโอทำให้คนหงุดหงิด บั๊กภาพแคปหลอก AI อย่างมองไม่เห็น เวลาคุณสร้างฟีเจอร์ที่ป้อนบริบทให้โมเดล input ที่ผิดจะผลิต output ที่ผิดอย่างมั่นใจ โดยไม่มี error ที่ไหนเลย นั่นคือความล้มเหลวที่ควรตามล่าให้หนักที่สุด
3. การแก้ที่ผ่านบนเครื่องคุณ อาจล้มเหลวบนเครื่องคนอื่นทั้งหมด เวอร์ชันที่ยึด overlay ทำงานได้ในเทสต์จอเดียว แต่ทั้งหมดทั้งมวลของบั๊กนี้คือการมีหลายจอ — และผู้ review เลือกที่จะใช้เหตุผลว่าตำแหน่งจริงของหน้าต่างอยู่ตรงไหน แทนที่จะเชื่อเทสต์สีเขียว การ review ไม่ใช่การประทับตรายางบนโค้ดที่รันได้; มันคือโมเดลตัวที่สองของ เหตุผลว่าทำไม โค้ดถึงทำงาน

GeekBye v2.0.10 ปล่อยการแก้แบบอิงเคอร์เซอร์สำหรับทั้งการบันทึกและการแคปหน้าจอ ถ้าคุณใช้หลายจอ การจับภาพจะตามคุณไปแล้วตอนนี้

สำหรับรีลีสข้างเคียงในซีรีส์นี้ ดูทำไม AI notetaker ของคุณถึงหยุดบันทึกเสียงกลางประชุม (v2.0.9) และทำไม AI ถอดเสียงถึงฟังศัพท์เทคนิคผิด (v2.0.11) สำหรับพฤติกรรมของ overlay ระหว่างการโทร ดูวิธีที่ overlay ยังคงล่องหนระหว่างการแชร์หน้าจอ