Vì sao ghi màn hình lại quay nhầm màn hình (và cách chúng tôi sửa)

Đây là một con bug chỉ tồn tại nếu bạn có hai màn hình — chính vì thế nó lặng lẽ sống một thời gian. Bạn làm việc trên màn hình bên cạnh, bắt đầu một bản ghi GeekBye, và nó lại ghi màn hình chính của bạn. Cái màn hình có thanh menu. Cái màn hình bạn không hề nhìn vào.

Cùng một khiếm khuyết, âm thầm hơn và tệ hơn, giáng vào những ảnh chụp màn hình mà GeekBye gửi cho AI làm bối cảnh: bấm phím tắt chụp màn hình trên màn hình thứ hai, và AI nhận được bức ảnh của màn hình thứ nhất. Không có dấu hiệu trực quan nào — trợ lý cứ thế trả lời về nhầm màn hình, còn bạn thì ngồi thắc mắc sao nó lú lẫn vậy. GeekBye v2.0.10 đã sửa cả hai.

Hai luồng, một giá trị mặc định lười biếng

Việc thu màn hình trên desktop là hai đường code tách biệt, và cả hai đều độc lập chọn màn hình chính:

• Ghi video liệt kê các nguồn màn hình khả dụng rồi lấy cái đầu tiên — sources[0]. Trên macOS đó thực tế luôn là màn hình chính. Không có bộ chọn, không có logic nào về việc bạn thực sự đang ở đâu. Comment trong chính code của chúng tôi viết đúng nguyên văn "auto-select first screen source."
• Ảnh chụp màn hình dùng lệnh screencapture của macOS với cờ -m. Cờ đó có đúng một nghĩa: main display only (chỉ màn hình chính). Cứng ngắc.

Cả hai đường đều chưa bao giờ đặt ra câu hỏi quan trọng nhất: người dùng đang ở màn hình nào?

Có một thứ chưa bao giờ hỏng, đáng nói rõ ra vì người ta hay tưởng nó hỏng: chuyển đổi giữa các macOS Spaces trên cùng một màn hình luôn hoạt động đúng. Việc thu diễn ra ở cấp màn hình — nó lấy bất kỳ Space nào đang hiển thị trên màn hình được chọn. Con bug này chưa bao giờ là về Spaces. Nó luôn là về việc chọn nhầm màn hình vật lý.

Bản sửa trông có vẻ hiển nhiên — và đã sai

Tín hiệu đúng có vẻ dễ: thu màn hình mà người dùng đang ở trên đó. Lần triển khai đầu tiên của chúng tôi neo vào cửa sổ overlay của GeekBye — thu bất kỳ màn hình nào mà overlay đang nằm.

Code review đã bác bỏ nó, và đúng đắn. Overlay của GeekBye được tạo như một cửa sổ phủ kín vùng làm việc trên màn hình chính, ở vị trí (0,0). Nó chỉ di chuyển sang màn hình khác nếu bạn tự tay kéo viên pill của nó sang đó — và các phím tắt dùng để nhích nó quanh màn hình bị kẹp (clamp) vào kích thước của màn hình chính, nên chúng không thể đẩy nó sang màn hình thứ hai được. Neo việc thu vào overlay nghĩa là: với mọi người dùng không tình cờ kéo overlay lên màn hình đang làm việc, "bản sửa" ấy lại quay thẳng về màn hình chính. Nó gần như chẳng sửa được cho ai — mà lại trông như đã chạy được, trong một bài test nhanh trên máy dev một màn hình.

Điểm neo đúng là con trỏ. Chuột của bạn ở đâu, đó chính là màn hình bạn đang làm việc — và nó đúng cho mọi cách một lần thu bắt đầu: phím tắt kích hoạt ngay nơi bạn đang trỏ, còn bấm nút Record thì theo định nghĩa con trỏ của bạn đã nằm trên màn hình đó. Bản sửa cuối cùng là một hàm hai dòng: màn hình gần con trỏ nhất. Video khớp nguồn thu của nó với id của màn hình đó; ảnh chụp truyền phạm vi (bounds) của màn hình đó cho screencapture -R (một hình chữ nhật cụ thể) thay vì cờ màn hình chính -m.

Chúng tôi cố tình chọn -R (một hình chữ nhật tường minh theo tọa độ màn hình toàn cục) thay vì -D (một chỉ số màn hình): chỉ số màn hình của hệ điều hành không có gì đảm bảo tương ứng với thứ tự màn hình của framework, nên dùng chỉ số sẽ lại là một trò đoán mò lần nữa. Một hình chữ nhật lấy từ phạm vi màn hình thực thì không mập mờ — và trước khi phát hành, chúng tôi đã kiểm chứng hành vi của cờ này, bao gồm cả tọa độ âm cho những màn hình đặt bên trái màn hình chính, trên một dàn nhiều màn hình thật.

Vì sao đây là một con bug dạy học tốt

1. "Thu màn hình" giấu bên trong một quyết định. Trên một màn hình duy nhất không có quyết định nào, nên quyết định đó chẳng bao giờ được thiết kế — nó bị để mặc định. Đa màn hình chính là nơi mọi giá trị mặc định ngầm lộ ra.
2. Sai âm thầm tệ hơn sai lộ liễu. Con bug video làm người ta khó chịu. Con bug ảnh chụp đánh lừa AI, một cách vô hình. Khi bạn xây những tính năng nạp bối cảnh cho một mô hình, một đầu vào sai sẽ tạo ra một đầu ra sai đầy tự tin mà chẳng có lỗi ở đâu cả. Đó mới là những thất bại đáng săn lùng ráo riết nhất.
3. Một bản sửa chạy được trên máy bạn có thể hỏng trên máy của mọi người khác. Phiên bản neo vào overlay chạy được trong bài test một màn hình. Cả điểm mấu chốt của con bug là nhiều màn hình — và người review đã lập luận về vị trí thực của cửa sổ thay vì tin vào bài test màu xanh. Review không phải là con dấu cao su đóng lên code đang chạy được; nó là một mô hình thứ hai về lý do vì sao code chạy được.

GeekBye v2.0.10 phát hành bản sửa dựa trên con trỏ cho cả ghi màn hình lẫn ảnh chụp. Nếu bạn dùng nhiều màn hình, việc thu giờ đây đi theo bạn.

Về các bản phát hành lân cận trong series này, xem vì sao AI notetaker của bạn dừng ghi âm giữa cuộc họp (v2.0.9) và vì sao AI phiên âm nghe nhầm thuật ngữ kỹ thuật (v2.0.11). Về cách overlay hành xử trong cuộc gọi, xem cách giữ mình vô hình khi chia sẻ màn hình.