Tiếng Việt

Hình ảnh & hình ảnh · Trình chuyển đổi & nén hình ảnh

Cách Web Workers và OffscreenCanvas giữ cho chuyển đổi hình ảnh phản hồi nhanh

· Cách thức hoạt động

browser-processing vải vẽ web-workers

Làn đường giao diện người dùng bên cạnh làn đường dành riêng cho công nhân có chứa canvas ngoài màn hình
Hình minh họa vector ToolAcre gốc

Mã hóa một hình ảnh lớn mất CPU thời gian thực và thực hiện việc đó trên luồng chính sẽ đóng băng trang. Bài đăng này giải thích cách Web Workers và OffscreenCanvas di chuyển hoạt động ra khỏi chuỗi giao diện người dùng cũng như ý nghĩa của kiến ​​trúc đó đối với quyền riêng tư và các giới hạn.

Tab sẽ bị treo - điều gì sẽ xảy ra khi một mã hóa nặng chạy trên chuỗi cũng vẽ trang

Việc giải mã, vẽ lại và mã hóa một loạt yêu cầu CPU hoạt động và bộ nhớ pixel được giải mã. Nếu mọi thao tác chạy trong cùng một vòng lặp sự kiện xử lý các điều khiển, cập nhật tiến trình và vẽ, thì giao diện có thể ngừng phản hồi cho đến khi hoàn thành một tệp. Do đó, bảng điều khiển tập trung tạo ra một trình chạy mô-đun một cách lười biếng khi chuyển đổi đầu tiên bắt đầu thay vì trả chi phí khởi động đó cho khách truy cập không bao giờ chuyển đổi.

Khả năng đáp ứng là mục tiêu kiến ​​trúc, không phải là con số thời gian đã hứa. Tải thiết bị, kích thước hình ảnh, triển khai trình duyệt và bố cục hàng loạt vẫn quyết định cảm giác của trang. Xác minh bằng các tệp đại diện trên các thiết bị quan trọng; không công bố thời lượng chuyển đổi phổ quát hoặc tuyên bố rằng một công nhân làm những công việc đắt tiền trở nên miễn phí.

Luồng chính và lý do tại sao nó lại quý giá — một luồng cho bố cục, đầu vào và tập lệnh cũng như thời lượng tác vụ chặn cả ba luồng này

Chuỗi chính sở hữu DOM và các điều khiển mà khách truy cập chạm vào. ToolAcre sử dụng nó để xác thực các lựa chọn, giải mã ngắn gọn các kích thước nguồn, cài đặt bản dựng, trạng thái hiển thị và kết quả tải xuống. Vòng lặp giải mã, vẽ canvas và mã hóa lặp lại của lô nằm sau `image.worker.js`, cho phép trả về thông báo tiến trình giữa các tệp.

Một công nhân không loại bỏ mọi tác vụ của luồng chính. Mỗi tệp đã chọn ban đầu được kiểm tra và đo lường trong bảng điều khiển, sau đó kết quả được chuyển thành bản xem trước và hành động tải xuống ở đó. Thiết kế di chuyển quy trình nặng nề lặp đi lặp lại khỏi quyền sở hữu giao diện trong khi vẫn giữ các API trình duyệt và bản trình bày trong ngữ cảnh của mỗi giao diện.

Nhân viên web: luồng thứ hai không có DOM — những gì nhân viên có thể và không thể chạm vào cũng như cách các tệp di chuyển đến đó

Nhân viên không có quyền truy cập DOM thông thường. Nó nhận được các mô tả, cài đặt mục có thể tuần tự hóa và ArrayBuffer của mỗi tệp. Đối với mọi mục, nó xây dựng cùng một kế hoạch chuyển đổi thuần túy được giao diện sử dụng, tạo Blob, thực thi giải mã-rút-mã hóa, chuyển đổi Blob kết quả thành byte và ghi lại lỗi trên mỗi tệp mà không bỏ qua phần còn lại của lô.

Sự cô lập đó cũng định hình việc xử lý lỗi. Một tệp bị hỏng có thể nhập vào mảng lỗi trong khi các mục sau đó vẫn tiếp tục. Nhân viên kiểm tra việc hủy bỏ giữa các mục và báo cáo tiến trình với tên tệp hiện tại. Giao diện người dùng chuyển thời gian chờ của nhân viên thành lời khuyên nên thử ít hình ảnh hơn hoặc nhỏ hơn thay vì để lại một nút bị vô hiệu hóa mà không có lời giải thích.

OffscreenCanvas: vẽ và mã hóa mà không có phần tử hiển thị - cách một nhân viên có được canvas của riêng mình và gọi ConvertToBlob

`createCanvas` ưu tiên `OffscreenCanvas` khi hàm tạo tồn tại. Bên trong đường dẫn đó, `encodeCanvas` gọi `convertToBlob` với loại MIME mục tiêu và chất lượng tùy chọn. Trình kết xuất tương tự cũng có thể tạo canvas HTML và sử dụng `toBlob` dựa trên lệnh gọi lại, duy trì dự phòng cho các bối cảnh không có OffscreenCanvas.

Điều quan trọng là phải mô tả chính xác dự phòng. OffscreenCanvas được ưu tiên hơn chứ không phải canvas duy nhất có thể có trong nguồn. Tương tự, mã hóa WebP của trình duyệt được kiểm tra bằng kết quả mã hóa cuối cùng thay vì giả định từ hỗ trợ giải mã. Ứng dụng hứa hẹn sẽ xảy ra lỗi khi bộ mã hóa được yêu cầu không thể tạo ra định dạng, không thay thế im lặng bằng loại MIME khác.

Có thể chuyển nhượng và sao chép - di chuyển ImageBitmap hoặc ArrayBuffer sang một nhân viên mà không cần sao chép hàng chục megabyte

Trước khi gọi nhân viên, bảng điều khiển sẽ đọc từng Tệp vào một ArrayBuffer và đưa các bộ đệm đó vào danh sách truyền. Quyền sở hữu chuyển sang công nhân thay vì sao chép mọi bộ đệm đầu vào. Sau khi mã hóa, nhân viên sẽ gói các byte Blob trong Uint8Array và đăng ký bộ đệm dự phòng đó để truyền trên đường dẫn phản hồi.

Điều này làm giảm việc sao chép có thể tránh được nhưng hình ảnh và khung vẽ được giải mã vẫn chiếm bộ nhớ. `executePlan` đóng mỗi ImageBitmap trong khối `finally` để các pixel đã giải mã của nó có thể được giải phóng kịp thời. Các nội dung có thể chuyển nhượng, dọn dẹp bitmap rõ ràng và bảo vệ ngân sách pixel giải quyết các nguồn áp lực khác nhau; không ai cho phép yêu cầu hàng loạt không giới hạn.

Tại sao cấu trúc này cũng là câu chuyện về quyền riêng tư — toàn bộ quy trình nằm trong tab của bạn và bảng điều khiển mạng vẫn ở trạng thái im lặng

Mã chuyển đổi gọi API hình ảnh và canvas của trình duyệt mà không cần yêu cầu tải tệp lên. Một đơn vị kiểm tra bảo vệ lập kế hoạch cho mọi kết hợp đầu vào-đầu ra được hỗ trợ khi truy cập mạng bị cấm. Điều khoản về quyền riêng tư của cấu hình tương ứng bị thu hẹp: mã công cụ không đưa ra yêu cầu mang tệp, văn bản đã dán hoặc đầu ra được tạo.

Bản thân trang vẫn có thể tải nội dung trang web và các tập lệnh bên ngoài được tiết lộ, do đó, "bảng điều khiển mạng im lặng" cần được giải thích. Xóa DevTools sau khi tải và tìm tên tệp thử nghiệm vô hại đặc biệt hoặc byte tải trọng trong các yêu cầu mới. Đánh giá nguồn và quan sát thời gian chạy cùng nhau hỗ trợ cho tuyên bố về đường dẫn chuyển đổi; không biến toàn bộ môi trường trình duyệt thành hộp cát ngoại tuyến.

Giới hạn đến từ đâu — giới hạn bộ nhớ và canvas thay thế giới hạn tải lên, vì vậy mức trần là thiết bị của bạn

Quá trình xử lý cục bộ thay thế giới hạn tải lên bằng các ràng buộc từ xác thực đầu vào, pixel được giải mã, phân bổ canvas và bộ nhớ thiết bị khả dụng. Mỗi tệp đầu vào được giới hạn ở 40 MB bởi bảng điều khiển có tiêu điểm. Hình dạng đầu ra theo kế hoạch được điều chỉnh phù hợp với ngân sách pixel của thiết bị và người dùng sẽ nhận được cảnh báo đặt tên cho các kích thước bị giảm khi người bảo vệ đó thay đổi yêu cầu.

Không có số lượng lô cố định trong cấu hình. Hai mươi đồ họa nhỏ và hai mươi bức ảnh có độ phân giải cao không phải là sự phân bổ tương đương. Điện thoại có thể hỏng sớm hơn máy tính để bàn. Lời khuyên vận hành trung thực là xử lý ít tệp hơn hoặc nhỏ hơn sau khi hết thời gian chờ hoặc lỗi bộ nhớ, không công bố số lượng tối đa hoặc trần megapixel không được hỗ trợ.

Bài học rút ra: công việc nặng nhọc, giao diện yên tĩnh - cách Trình chuyển đổi & Máy nén Hình ảnh thực hiện các chuyển đổi ngoài luồng chính trên thiết bị của bạn

Giao diện vẫn yên tĩnh hơn vì quy trình lặp lại chạy trong một trình chạy, khung vẽ của nó có thể nằm ngoài màn hình và các bộ đệm byte lớn di chuyển dưới dạng có thể chuyển được. Đó là những thuộc tính nguồn cụ thể, không phải là cách viết tắt tiếp thị. Họ giải thích nơi công việc diễn ra và tiến độ quay trở lại như thế nào mà không tuyên bố rằng mọi trình duyệt đều lên lịch cho công việc đó như nhau.

Kiểm tra kiến ​​trúc bằng những hình ảnh mà quy trình làm việc của bạn thực sự sử dụng. Theo dõi các điều khiển trong quá trình chuyển đổi, xác nhận tiến trình trên mỗi tệp, kiểm tra lỗi và kiểm tra bảng Mạng để tìm điểm đánh dấu kiểm tra. Thiết kế của ToolAcre cung cấp cho bạn bằng chứng có thể quan sát được: một mô-đun công nhân thực sự, kết quả đầu ra được đo lường và byte tải xuống cục bộ thay vì một công việc từ xa không rõ ràng.