REFERATUA.ORG.UA — База українських рефератів




до картинок, створеним програмою, але і до вікон, меню, іконкам і т.п.

QNX Windows використовує наступні типи елементів:

arc

дуга еліпса

button

кнопка

curve

крива Безьє 3-го порядку

group

комбінований елемент визначений програмістом

image

довільний кольоровий растр, від 4 до 16 біт на піксель

line

лінія

link

посилання на інший елемент

number

число ( чиціле з крапкою, що плаває,)

paragraph

параграф тексту (з табуляцією, відступами і шрифтом)

pixmap

растр, у форматі залежному від пристрою висновку

points

полігон (можливо замнкутый)

rectangle

прямокутник

symbol

довільний растр, що містить до 16 бітових площин

string

простий неформатованный текст

text

форматованный текст (з довільним шрифтом)

З будь-яким елементом може бути асоційована мітка (label), діалог чи довільні дані, визначені програмістом. У залежності від типу, елементи мають характерний набір атрибутів (координати, колір, колір тіла, товщина ліній, шрифт і т.п.). Елементи всіх типів можуть мати також опції (options) і стану (states), що визначають поводження елемента і спосіб його висновку. По поводженню при натисканні на нього мишею, елемент може бути 'обираним' (selectable), що редагується, ' щоповідомляє' (notify), блокованим, що інвертує чи стан запам'ятовує стан. Виводитися елемент може стандартно, безпосередньо у вікно (минаючи картинку), із затемненням, з рамкою, з 3D-ефектом, з тінню.

Описуються елементи з незалежним від пристрою способом, за допомогою спеціальних структур даних. Упорядкована сукупність таких описів, постачена заголовком, утворить стандартну картинку (елементи існують тільки усередині картинок). Така картинка може бути збережена у файлі формату PICT і прочитана з нього.

Як уже згадувалося вище, елементами можна маніпулювати. Основним засобом ідентифікації елементів служить ім'я елемента (звичайно називане тегом). При цьому можуть використовуватися шаблони, схожі на шаблони імен файлів, що дозволяє ідентифікувати для однієї операції групу елементів (чи усі). Крім того, для ідентифікації може бути використана будь-яка комбінація опцій, що обмежує список елементів до бажаного складу (наприклад, можна специфікувати усі 'обирані' елементи), послідовний номер елемента в картинці, координати, прямокутна область картинки і т.д.

Для того, щоб зробити що-небудь з картинкою, додаток спецефікує елементи і вказує операцію, яку потрібно до них застосувати. З іншого боку, елементами може маніпулювати користувач, наприклад редагуючи значення текстового чи рядка змінюючи значення числа. У цьому випадку власник відповідного ресурсу (звичайно це процес створивший його), одержить відповідне повідомлення, якщо він замовляв подібне повідомлення. Інший підхід полягає в тому, що нові значення елементів можна запросити тоді, коли вони реально знадобляться. Процес-власник може також передати свої повноваження іншому процесу.

Для мінімізації вихідного коду QNX Windows використовує поняття графічного контексту, у якому зберігаються поточні значення ресурсів і атрибутів елементів усіх типів. Графічний контекст теж може бути збережений у файлі і відновлений відтіля.

Розглянуті вище концепції дозволили розроблювачам QNX Windows застосувати трохи дуже красивих і ефективних рішень, деякі з який не мають аналогів.

По-перше, усі ресурси, створювані додатками (вікна, картинки, діалоги) створюються менеджером екрана і зберігаються в його адресному просторі. Це радикально зменшує вимоги програм до оперативної пам'яті і підвищує швидкість виконання графічних операцій. Саме в цьому головну відмінність графічних елементів QNX Windows від виджетов X Window, що хоча і маскують від додатка деталі своєї роботи, але зберігаються в адресному просторі додатка. При цьому сервер у X Window усього лише виконує X Protocol, що має досить низький рівень. Наслідком цього є не тільки високий внутрішній трафік але і той менш помітний факт, що нитка керування при модифікації вмісту екрана дуже часто передається додатку, що дуже небажано для додатків реального часу. У QNX Windows усі зовсім інакше, тому що додаток повинний тільки замовити високорівневу операцію серверу, а виконує він її без подальшого втручання. При цьому витрати пам'яті на сервері теж невеликі, оскільки поняття типу елемента дозволяє відмовитися від збереження растрів, застосовуючи замість них картинки (сервер знає як малювати елементи відомого йому типу). Це злегка нагадує ОС NextStep, де зображення зберігаються у форматі Display PostScript, але картинки QNX Windows вимагають на порядок менше пам'яті (пом'ятаєте, що для кольоровий NextStep потрібно 64Mb пам'яті?) тому що PostScript описує абстрактні команди малювання, а не об'єкти визначених типів. По-друге, можливість групової ідентифікації елементів знижує трафік повідомлень і дозволяє серверу оптимізувати виконання графічних операцій. Крім того, це сильно спрощує логіку і розмір прикладних програм, про що ше буде сказано далі.

По-третє, маючи у своєму розпорядженні всі картинки і вікна, сервер може сам відслідковувати перекриття вікон, обчислювати відсікання і виконувати перемальовування умісту вікон! Це означає, що програма в QNX Windows не зобов'язана обробляти повідомлення типу EXPOSE чи WM_PAINT, як це приходиться робити в системах X Window чи MS Windows. Режим Backing Store, що з'явився в X Window System release 11, не йде ні в яке порівняння, оскільки там зберігаються растри, і у випадку недостачі пам'яті (що дуже ймовірно) сервер цей режим виключає (тобто програма не може і не повинна на нього покладатися). Звичайно, будь-яка проміжна ступінь вносить затримки, тому для програм, критично залежних від швидкості висновку на екран, передбачений режим прямого висновку елементів у вікно.

По-четверте, менеджер екрана може автоматично забезпечувати бажане поводження вікон і кватирок, що задається набором опцій, як і у випадку


 
Загрузка...