/  
 ДОКУМЕНТІВ 
20298
    КАТЕГОРІЙ 
30
Про проект  Рекламодавцям  Зворотній зв`язок  Контакт 

OC QNX, Детальна інформація

Тема: OC QNX
Тип документу: Реферат
Предмет: Комп`ютерні науки
Автор: фелікс
Розмір: 0
Скачувань: 1379
Скачати "Реферат на тему OC QNX"
Сторінки 1   2   3   4   5  
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, не йде ні в яке порівняння, оскільки там зберігаються растри, і у випадку недостачі пам'яті (що дуже ймовірно) сервер цей режим виключає (тобто програма не може і не повинна на нього покладатися). Звичайно, будь-яка проміжна ступінь вносить затримки, тому для програм, критично залежних від швидкості висновку на екран, передбачений режим прямого висновку елементів у вікно.

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

Більш того, деякі типові ситуації сервер може обробляти самостійно, наприклад видавати повідомлення при введенні користувачем значення, що виходить за границі зазначеного діапазону, автоматично виводити смуги прокручування при якщо картинка не міститься в кватирку цілком і підтримувати скролінг. Вікно може містити елементи зі стандартними тегами, при натисканні на який сервер буде виконувати стандартні дії. Для елементів можна задати їхнє поводження при проходженні над ними чи курсору при натисканні на них.

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

Ті, хто має досвід програмування в X Window, знають, що програми для цієї системи надзвичайно багатослівні. Величезна кількість функцій API робить його важкодоступним до огляду і ускладнює життя програмістам, через що для X Window була написана найбільша кількість генераторів коду. Мінімальна програма, що виводить у вікно напис hello world! має довжину близько 30 рядків, що ще дуже непогано в порівнянні з MS Windows. Розмір модуля, що виконується, виходить близько 800 Kb, у залежності від конкретної реалізації. У QNX Windows така програма виходить усього на двох рядків довше, ніж класичний варіант Керингана і Рітчі, якщо використовувати стандартний діалог, і ще на дві строчки довше, якщо використовувати звичайне вікно. Розмір модуля, що виконується, 7500 байт, при запуску програма займає 92 Kb (32-х розрядна версія, flat-модель).

#include

void main ( void )

{

GraphicsOpen( NULL ); // з'єднання із сервером

Tell( "Hello Program", "Hello, World!" );

GraphicsClose( 0 );

}

Однак, як справедливо замічено в книзі X Toolkit Рrоgrаммеr's Manual, програма hello world! є виродженим прикладом для X Window. Якщо наростити приведену програму до тих можливостей настроювання які надає версія для X Window, ми одержимо порівнянний розмір вихідного коду (однак розмір виконуючого модуля зміниться дуже незначно!!!).

Проте, розглянемо ще один приклад. У комплект постачання OSF/Motif 1.2 входить демонстраційна програма DNDDemo, що дає приклад використання протоколу Drag and Drop, що з'явився в цій версії інтерфейсу Motif. Розмір вихідного коду цієї програми близько 3000 рядків мовою “С”, розмір модуля, що виконується, (у версії X Window для QNX) - близько 900 Kb. Для порівняння автор даної статті написав програму для QNX Windows еквівалентну функціональність, що забезпечує. Програма створює вікно з двома кватирками, у нижній кватирці розміщені 16 кольорових прямокутників. Користувач може малювати прямокутники у верхній кватирці, використовуючи звичайний механізм 'гумової нитки'. Намальовані прямокутники можна чи копіювати переміщати мишею як у межах кватирки, так і у верхню кватирку іншого вікна, відкритого іншою копією програми. Колір будь-якого прямокутника можна змінити, 'перетягнувши' бажаний колір з палітри в нижній кватирці.

При цьому підтримуються візуальні ефекти Drag Over (зміна курсору), Drag Under (узяття прямокутника в рамку) і контекстно-залежна функція Help. Розмір вихідного коду - 300 (триста) рядків мовою C. Розмір модуля, що виконується, (32-х розрядна версія, компілятор Watcom C 9.51) - 15 (п'ятнадцять) Kb. Обсяг статті не дозволяє привести тут вихідний текст програми, але автор готовий надати його по запиті всім бажаючим.



12.Висновок

ОС QNX і система QNX Windows з успіхом застосовувалася при реалізації багатьох великих проектів, деякі з який самі по собі досить цікаві, щоб написати про їх окрему статтю. Як приклади можна привести застосування QNX для систем сортування вхідного транспорту і продажу квитків на терміналах залізничної магістралі між Францією і Великобританією, прокладеної в тунелі під протокою Ла-Манш. Проектна пропускна здатність цієї магістралі в годинник списів - один склад кожні 2.5 хвилини, швидкість проходження потягів - 100 миль у годину, що висуває підвищені вимоги до кваліфікації машиністів. Для рішення цієї проблеми був створений спеціальний тренажерний центр, що використовує технологію віртуальної реальності для 100% імітації реальної обстановки в кабіні локомотива. QNX Windows була використана для створення візуальної підсистеми, що забезпечує возпроизведение оцифрованих зображень навколишнього пейзажу з частотою 25 кадрів/сек. Система імітує також звукові і гравітаційні ефекти.

Інший недавній приклад - централізована система керування морськими нафтовими платформами, створена в Новій Зеландії, що дозволяє здійснювати контроль над процесом перекачування нафти на всіх установках у режимі on-line через дистанційні датчики.

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

Міністерство освіти і науки України

Сторінки 1   2   3   4   5  
Коментарі до даного документу
Додати коментар