Контекст пристрою
Контекст пристрою (DC — Device Context) — структура даних, що створюється інтерфейсом GDI для представлення підключених пристроїв. Наприклад, щоб мати можливість відобразити зображення на екрані, додатку Windows необхідний контекст пристрою екрану, а для організації виводу на друк необхідний контекст іншого пристрою — принтера. Якщо тому ж самому застосуванню знадобиться організувати виведення зображення в метафайл і растр, то потрібно буде додати контексти третього і четвертого пристроїв. Фактично, роль контексту пристрою полягає в забезпеченні обміну даними між додатком і фізичним пристроєм (або псевдопристроєм).
Окрім забезпечення взаємодії з пристроєм, в обов'язки контексту пристрою входить зберігання набору встановлених графічних атрибутів. Наприклад, щоб з'ясувати колір тексту, що відображається, функція відображення звертається при виклику до атрибуту кольору тексту.
Значення будь-якого графічного атрибуту можна змінити, викликаючи певні функції GDI. Наприклад, колір тексту встановлює функція SetTextColor. Кожній функції установки атрибуту відповідає функція повернення значення цього атрибуту. Отже, щоб з'ясувати поточне значення кольору тексту, досить викликати функцію GetTextColor.
Повідомлення wm_paint
Найважливішим повідомленням для промальовування є WM_PAINT. У найпростішому випадку це повідомлення оповіщає вікно про необхідність перемальовування його вмісту. Повідомлення WM_PAINT може бути передане з багатьох причин. Наприклад, інше вікно могло бути відкрите поверх даного вікна і частково закрити його вміст . Або користувач може розвернути або відновити раніше згорнуте вікно. Крім того, це повідомлення може бути передане ^росто тому, що програма була тільки що запущена і її вікно необхідно промальовувати. | Основною причиною, по якій вікна повинні приймати і обробляти повідомлення WM_PAINT, є те, що система нездібна самостійно відновлювати втрачений вміст клієнтської області вікна. Група розробників Windows розглядала спочатку різні способи, за допомогою яких система могла б зберігати зображення вікна. Один з даних підходів полягав в отриманні і збереженні знімка вікна перед тим, як його закриє інше окно6. Проте величезний об'єм пам'яті, необхідної для цього підходу, зробив подібне рішення нездійсненним.
В світі символьних екранів що всі відображаються на екрані дані можуть бути збережені в крихітному буфері розміром порядка 2 Кбайт. Але, як вже було сказано, розмір буфера, необхідного для зберігання зображення екрану 640x480 пікселів на 256 квітів, складає приблизно 300 Кбайт. Це 300 000 байт по порівнянню 2 000 байт! Всього лише три вікна займуть цілий мегабайт (і це при мінімальних характеристиках дисплея); а як бути, якщо одночасно запущено декілька застосувань? Для перших версій Windows, коли оперативна пам'ять комп'ютерів складала всього лише 1 Мбайт, ця ціна була дуже висока.
Навіть якщо об'єм пам'яті достатньо великий, залишається інша проблема. Якщо система зберігатиме знімки екранів при кожній частковій зміні даних вікон, кешування стане безглуздим. У такій ситуації додаток вимушений перемальовувати вміст вікон регулярно. В результаті, вся пам'ять і велика частина часу процесора були б даремно витрачені на збереження і відображення знімків. Таким чином, технологія знімків екрану — це, в кращому разі, неефективне рішення.
Отже, застосування повідомлення WM_PAINT залишається якнайкращим вирішенням проблеми підтримки поточного стану вікна. Всю відповідальність за підтримку вмісту своїх вікон операційна система Windows повністю покладає на само застосування. Таким чином, повідомлення WM_PAINT забезпечує роботу механізму, за допомогою якого операційна система повідомляє додаток про те, що прийшло час відновити вікно. Все, що необхідно зробити розробникові, — це гарантувати, що додаток здатний зберігати всю інформацію про стан, необхідну для виконання цього завдання.