Gambar & foto · Konverter & Kompresor Gambar
Bagaimana Web Workers dan OffscreenCanvas menjaga konversi gambar tetap responsif
· Cara kerjanya
pemrosesan browser kanvas pekerja web
Pengkodean gambar besar membutuhkan waktu CPU, dan melakukannya di thread utama akan membekukan halaman. Postingan ini menjelaskan bagaimana Pekerja Web dan OffscreenCanvas memindahkan pekerjaan tersebut dari thread UI dan apa arti arsitektur tersebut bagi privasi dan batasan.
Tab yang akan terhenti — apa yang terjadi ketika enkode berat dijalankan pada thread yang juga menggambar halaman
Mendekode, menggambar ulang, dan mengkodekan suatu batch memerlukan CPU kerja dan memori piksel yang didekodekan. Jika setiap operasi dijalankan dalam loop peristiwa yang sama yang menangani kontrol, pembaruan kemajuan, dan pengecatan, antarmuka dapat berhenti merespons hingga file selesai. Oleh karena itu, panel terfokus membuat pekerja modul dengan malas saat konversi pertama dimulai daripada membayar biaya awal untuk pengunjung yang tidak pernah berkonversi.
Daya tanggap adalah tujuan arsitektural, bukan angka waktu yang dijanjikan. Pemuatan perangkat, dimensi gambar, implementasi browser, dan komposisi batch masih menentukan seberapa lancar halaman tersebut terasa. Verifikasi dengan file representatif pada perangkat yang penting; jangan mempublikasikan durasi konversi universal atau mengklaim bahwa seorang pekerja membuat pekerjaan yang mahal menjadi gratis.
Thread utama dan mengapa itu berharga — satu thread untuk tata letak, input dan skrip, dan berapa lama tugas memblokir ketiganya
Thread utama memiliki DOM dan kontrol yang disentuh pengunjung. ToolAcre menggunakannya untuk memvalidasi pilihan, mendekode secara singkat dimensi sumber, pengaturan build, status render, dan hasil pengunduhan. Dekode berulang, gambar kanvas, dan loop enkode dari batch berada di belakang `image.worker.js`, sehingga pesan kemajuan dapat dikembalikan antar file.
Seorang pekerja tidak menghilangkan setiap tugas thread utama. Setiap file yang dipilih awalnya diperiksa dan diukur di panel, dan hasilnya kemudian diubah menjadi pratinjau dan tindakan pengunduhan di sana. Desain ini menjauhkan alur pipa berat yang berulang dari kepemilikan antarmuka sekaligus menjaga API browser dan presentasi dalam konteks masing-masing.
Pekerja Web: thread kedua tanpa DOM — apa yang dapat dan tidak dapat disentuh oleh pekerja, dan bagaimana file berpindah ke sana
Pekerja tidak memiliki akses DOM biasa. Ia menerima deskripsi item yang dapat diserialkan, pengaturan dan ArrayBuffer setiap file. Untuk setiap item, ia membangun rencana konversi murni yang sama dengan yang digunakan oleh antarmuka, membuat Blob, mengeksekusi decode-draw-encode, mengonversi Blob yang dihasilkan menjadi byte, dan mencatat kegagalan per file tanpa mengabaikan sisa batch.
Isolasi itu juga membentuk penanganan kesalahan. File yang rusak dapat masuk ke dalam array kegagalan sementara item selanjutnya berlanjut. Pekerja memeriksa pembatalan antar item dan melaporkan kemajuan dengan nama file saat ini. UI menerjemahkan waktu tunggu pekerja menjadi saran untuk mencoba gambar yang lebih sedikit atau lebih kecil daripada membiarkan tombol dinonaktifkan tanpa penjelasan.
OffscreenCanvas: menggambar dan mengkodekan tanpa elemen yang terlihat — cara pekerja mendapatkan kanvasnya sendiri dan memanggil convertToBlob
`createCanvas` lebih memilih `OffscreenCanvas` jika konstruktornya ada. Di dalam jalur tersebut, `encodeCanvas` memanggil `convertToBlob` dengan jenis target MIME dan kualitas opsional. Perender yang sama juga dapat membuat kanvas HTML dan menggunakan `toBlob` berbasis panggilan balik, mempertahankan fallback untuk konteks ketika OffscreenCanvas tidak tersedia.
Fallback penting untuk dijelaskan secara akurat. OffscreenCanvas lebih disukai, bukan satu-satunya kanvas yang mungkin ada di sumbernya. Demikian pula, pengkodean WebP browser diperiksa berdasarkan hasil penyandian akhir, bukan diasumsikan dari dukungan dekode. Aplikasi menjanjikan kesalahan ketika pembuat enkode yang diminta tidak dapat menghasilkan format, bukan substitusi senyap dengan tipe MIME lainnya.
Dapat ditransfer dan disalin — memindahkan ImageBitmap atau ArrayBuffer ke pekerja tanpa menduplikasi puluhan megabita
Sebelum memanggil pekerja, panel membaca setiap File ke dalam ArrayBuffer dan menyertakan buffer tersebut dalam daftar transfer. Kepemilikan berpindah ke pekerja alih-alih mengkloning setiap buffer input. Setelah pengkodean, pekerja membungkus byte Blob dalam Uint8Array dan mendaftarkan buffer pendukung tersebut untuk transfer pada jalur respons.
Hal ini mengurangi penyalinan yang tidak dapat dihindari, namun gambar dan kanvas yang didekodekan masih menempati memori. `executePlan` menutup setiap ImageBitmap dalam blok `finally` sehingga piksel yang didekodekan dapat segera dilepaskan. Pembersihan bitmap eksplisit yang dapat dialihkan dan perlindungan anggaran piksel mengatasi berbagai sumber tekanan; tidak ada yang mengizinkan klaim batch yang tidak terbatas.
Mengapa arsitektur ini juga merupakan kisah privasi — seluruh saluran ada di tab Anda, dan panel jaringan tetap diam
Kode konversi memanggil API gambar dan kanvas browser tanpa permintaan unggah file. Pengujian unit menjaga perencanaan untuk setiap kombinasi input-output yang didukung dengan akses jaringan dilarang. Pernyataan privasi konfigurasi juga sempit: kode alat tidak membuat permintaan untuk membawa file, teks yang ditempel, atau keluaran yang dihasilkan.
Halaman itu sendiri masih dapat memuat aset situs dan mengungkapkan skrip eksternal, sehingga “panel jaringan senyap” memerlukan interpretasi. Hapus DevTools setelah memuat dan cari nama file pengujian atau byte muatan yang tidak berbahaya dalam permintaan baru. Tinjauan sumber dan observasi waktu proses bersama-sama mendukung klaim tentang jalur konversi; tidak ada yang mengubah seluruh lingkungan browser menjadi kotak pasir offline.
Dari mana batasan tersebut berasal — batas memori dan kanvas menggantikan batas unggahan, sehingga batas atas adalah perangkat Anda
Pemrosesan lokal menggantikan batas unggahan dengan batasan dari validasi masukan, piksel yang didekodekan, alokasi kanvas, dan memori perangkat yang tersedia. Setiap file masukan dibatasi pada 40 MB oleh panel fokus. Geometri keluaran yang direncanakan disesuaikan dengan anggaran piksel perangkat, dan pengguna menerima peringatan yang menyebutkan dimensi yang dikurangi ketika pelindung tersebut mengubah permintaan.
Tidak ada jumlah batch tetap dalam konfigurasi. Dua puluh grafik kecil dan dua puluh foto resolusi tinggi bukanlah alokasi yang setara. Ponsel bisa gagal lebih awal dari desktop. Saran operasional yang sebenarnya adalah memproses file yang lebih sedikit atau lebih kecil setelah waktu habis atau kegagalan memori, bukan untuk mempublikasikan jumlah maksimum atau batas megapiksel yang tidak didukung.
Kesimpulan: antarmuka yang berat dan senyap — cara Konverter & Kompresor Gambar melakukan konversi dari thread utama di perangkat Anda
Antarmuka tetap lebih tenang karena alur berulang berjalan di pekerja, kanvasnya dapat berada di luar layar dan buffer byte besar berpindah sebagai dapat ditransfer. Itu adalah properti sumber yang konkrit, bukan singkatan pemasaran. Mereka menjelaskan di mana pekerjaan dilakukan dan bagaimana kemajuan terjadi tanpa mengklaim bahwa setiap browser menjadwalkannya secara sama.
Uji arsitektur dengan gambar yang sebenarnya digunakan alur kerja Anda. Perhatikan kontrol selama konversi, konfirmasi kemajuan per file, periksa kegagalan, dan periksa panel Jaringan untuk penanda pengujian. Desain ToolAcre memberi Anda bukti yang dapat diamati: modul pekerja nyata, keluaran terukur, dan byte unduhan lokal, bukan pekerjaan jarak jauh yang buram.