Pertimbangan Performa dan Praktik Terbaik
Topik ini menyajikan serangkaian praktik terbaik untuk menggunakan API Desktop Window Manager (DWM).
Topik ini berisi bagian berikut:
Praktik Aplikasi untuk DWM
Jika aplikasi Anda menangani penskalaan titik per inci (dpi), Anda dapat mendeklarasikan aplikasi sebagai sadar dpi dan mencegah penskalaan otomatis dengan mengatur bendera sadar dpi dalam manifes program atau dengan memanggil fungsi SetProcessDPIAware selama inisialisasi program.
Dengan komposisi DWM diaktifkan, aplikasi yang tidak jelas tidak lagi menerima pesan WM_PAINT dan tidak diminta untuk dirender ulang. Konten setiap jendela sudah tersedia untuk menyusun gambar layar.
Jendela WS_EX_TRANSPARENT tingkat atas harus dikombinasikan dengan gaya WS_EX_LAYERED untuk tujuan pengujian hit. WS_EX_TRANSPARENT dalam arti klasik, tanpa pengalihan, berguna untuk jendela anak dalam hierarki jendela yang termasuk dalam utas yang sama, tetapi tidak ditujukan untuk jendela tingkat atas.
Gunakan wilayah atau lapisan untuk membuat jendela berbentuk atau campuran. Perhatikan bahwa di Windows Vista dan versi Windows yang lebih baru, gambar kustom hanya sebagian dari jendela tingkat atas tidak akan menyediakan konten basi yang diinginkan di wilayah yang tidak diurungkan.
API seperti GetDCOrgEx dapat digunakan untuk menentukan nilai aktual tertentu. Jika Anda memiliki konteks perangkat (DC) untuk jendela yang dialihkan, asal yang dikembalikan oleh GetDCOrgEx tidak akan cocok dengan asal jendela Anda di layar. Asalnya akan menjadi asal permukaan back-buffer untuk jendela Anda: (0, 0).
Ketika semua hal lain gagal, nonaktifkan penyajian jendela dengan memanggil fungsi DwmSetWindowAttribute .
Praktik Menggambar untuk DWM
Hindari menggambar langsung ke permukaan tampilan utama. Melakukannya akan memaksa DWM untuk menonaktifkan komposisi hingga aplikasi Anda merilis permukaan perangkat utama.
Evaluasi apakah aplikasi Anda harus menyediakan buffering gandanya sendiri. DWM secara efektif menggandakan konten buffer dan menyajikan jendela dalam satu bingkai.
Hindari membaca dari atau menulis ke DC tampilan. Meskipun didukung oleh DWM, kami tidak merekomendasikannya karena penurunan performa.
Hindari menggambar di area non-klien. Meskipun area ini dapat diakses oleh aplikasi, dan menggambar di sana didukung oleh MICROSOFT Win32 API, melakukan ini dapat menyebabkan jendela kehilangan batas kaca apa pun yang dimilikinya.
Hindari mencampur Windows Graphics Device Interface (GDI) dan Microsoft DirectX kecuali tidak tumpang tindih. Jika pencampuran diperlukan, gambar konten GDI ke permukaan perangkat lunak DirectX dan gabungkan sebelum menyusunnya ke layar, atau menggambarnya di jendela terpisah.
Gunakan fungsi BitBlt atau StretchBlt alih-alih Windows GDI+ untuk menyajikan gambar Anda untuk penyajian. GDI+ merender satu baris pemindaian pada satu waktu dengan penyajian perangkat lunak. Hal ini dapat menyebabkan kedipan dalam aplikasi Anda.
Wilayah Klien Blur-Behind DWM
Merender efek blur-behind adalah operasi intensif sumber daya untuk CPU dan unit pemrosesan grafis (GPU). Pengembang aplikasi didesak untuk mempertimbangkan implikasi penggunaan kabur area klien sehingga tidak mengonsumsi sumber daya yang berlebihan. Anda harus berhati-hati dalam kasus berikut:
- Ketika Anda mengharapkan ukuran kabur area klien menjadi signifikan, bahkan jika tidak ada pembaruan yang akan terjadi di area kabur itu sendiri. Kabur harus dirender jika ada pembaruan yang terjadi di bawah area jendela yang kabur, yang menimbulkan biaya CPU dan GPU. Selain itu, operasi jendela pada jendela (pindah/mengubah ukuran/transisi) akan dikenakan lebih banyak biaya.
- Ketika Anda mengharapkan pembaruan signifikan di area klien yang kabur. Ini akan memerlukan pengecatan ulang kabur pada setiap pembaruan dan mengonsumsi sumber daya yang berlebihan.
- Jika kabur diharapkan mencakup area yang signifikan, dan pembaruan untuk area tersebut juga diharapkan, kami sangat menyarankan Agar Anda tidak mengaburkan area klien.