Волей судьбы и усилиями прессы, сложилось так, что для большинства людей понятие "графический пользовательский интерфейс" прочно ассоциируется с MS Windows. С этим фактом видимо уже ничего не поделаешь, но все как-то забыли, что Windows представляет собой не столько графическую, сколько операционную систему, выполняющюю многие задачи не связанные с графикой. Многочисленные обзоры и сравнения Windows и OS/2 касаются в основном их возможностей как операционных систем. Что же касается концепций работы с графикой, то здесь почти полный штиль, поскольку обе системы очень похожи. Долгожданная Windows 95 тоже представляет собой всего лишь 32-х разрядную (почти !) версию Windows 3.11, с новым пользовательским интерфейсом и улучшенной (но все еще плохой) многозадачностью.
Между тем, за пределами Microsoft тоже есть жизнь, а творческая мысль не остановилась после появления Windows. Графические системы, концептуально отличные от MS Windows, были в свое время предложены в проектах X Window, NextStep и некоторых других. Сегодня придумать что-нибудь действительно новенькое уже довольно сложно, так что если это кому-то удается, то очевидно заслуживает внимания. Данная статья посвящена обзору и анализу графической системы Photon, базирующейся на совершенно новых идеях. Система предназначена для операционной системы QNX (см. "Открытые системы 2/95") но концепции, реализованные в ней настолько оригинальны, что ознакомиться с ними имеет смысл любому специалисту в области графических систем, даже если он не работет с ОС QNX.
Читателям, знакомым с ОС QNX известно, что для этой системы уже давно существуют две графических оболочки - QNX Windows и X Window. Тем не менее, фирма QSSL пошла на разработку совершенно новой системы, несмотря на значительные издержки. Объясняется этот факт тем обстоятельством, что обе указанные оболочки были разработаны достаточно давно, причем посторонними фирмами, и ни одна из них не реализует в полной мере возможности, предоставляемые ОС QNX в ее современном виде.
Одно из ключевых определений, применяемых по отношению к QNX - термин "масштабируемая". Имено здесь находится ахиллесова пята практически всех известных графических систем - ни MS Windows, ни OS/2, ни X Window, ни даже QNX Windows не являются масштабируемыми в достаточной степени, для того чтобы их можно было использовать в системах c ограниченными ресурсами. В то-же время QNX ориентирована в первую очередь на встроенные системы реального времени, что предопределяет необходимость в графической системе, способной эффективно работать при ограниченных ресурсах.
Таким образом, основной задачей разработчиков было построение графической системы, столь-же масштабируемой, распределенной, открытой и эффективной, как сама ОС QNX. Решение этой задачи потребовало применения нетрадиционных подходов и оригинальных технологий. Результатом стала система, уже отмеченная наградами многих выставок и журналов, в том числе наградой журнала BYTE 1995 года за самую оригинальную технологию и Grand-Prix на Парижской выставке Real-Time Systems 1995 года. Система выдвинута также на соискание премии EDN, за лучшую новую технологию 1995 года. Кроме того, фирма QNX Software Systems Ltd. (QSSL), получила патент на систему Photon.
Модульность и масштабируемость
Единственный способ построить масштабируемую систему состоит в применении модульной архитектуры. Эта идея достаточно очевидна, но до сих пор не была реализована в полной мере в коммерческих системах. Причина состоит в том, что модульность подразумевает интенсивный обмен между модулями. В то-же время, в большинстве коммерческих ОС механизмы обмена данными и синхронизации между процессами реализованы не очень эффективно. В результате разработчики графических подсистем обычно жертвуют модульностью ради эффективности. Система Photon предназначена для ОС QNX в которой обмен сообщениями реализован достаточно эффективно и используется в качестве основного механизма взаимодействия между процессами.
Кроме того, модульная архитектура при неудачном проектировании порождает громоздкие, труднопонимаемые и труднорасширяемые системы. Говорят, что хорошо летает только тот самолет, который выглядит элегантно. Для того, чтобы любая модульная система хорошо работала, в ее основе должна лежать какая-то красивая идея. Система Photon обязана своими качествами идее пространства событий.
Распределенное пространство событий
В любой графической системе есть понятие событий. Обычно событие характеризуется определенным набором атрибутов, в том числе координатами объекта, с которым оно связано. Ядро системы отвечает за определение адресата, то есть модуля который должен обработать событие. События и объекты существуют в одной плоскости.
Основная суть идеи, реализованной в системе Photon, состоит в введении третьей координаты - оси событий. В результате события и объекты связываются в единое пространство. Как будет показано далее, фрагменты этого пространства могут быть распределены по узлам сети, поэтому разработчики системы используют выражение "распределенным пространство событий". Эта концепция, несмотря на свою простоту, имеет очень интересные следствия.
Событие представляет собой сообщение ОС QNX с определенной структурой и семантикой, посылаемое всем "заинтересованным" приложениям ядром системы Photon. Этот факт обычно скрыт от приложений, поскольку прикладной интерфейс системы Photon оперирует именно понятием "событие", а не "сообщение". Это, однако, не мешает приложениям системы Photon получать обычные сообщения.
Поскольку события существуют в пространстве, они (как и регионы) имеют координаты, причем не обязательно точечные. Каждое событие характеризуется прямоугольной областью, определяющей зону действия события и положение события относительно оси событий. Все события распространяются вдоль этой оси в одном из двух направлений. При возбуждении события, для него задаются источник (регион, от которого оно начинает двигаться), адресат и направление распространения. Возможна также прямая доставка событий от источника к адресату (прыжком).
Под чувствительностю понимается способность региона "замечать" указанные события, "проходящие" через него. Под непрозрачностью понимается способность региона вырезать из области указанных событий ту часть, которая пересекается с его собственной областью. Каждый регион имеет также и владельца - приложение, который будет уведомляться о событиях, к которым регион чувствителен. Иначе говоря, регион это агент приложения в пространстве событий.
При прохождении события через регионы, непрозрачные для него, область определения события трансформируется. Если первоначально эта область представляет собой прямоугольник, то при поступлении события к адресату она, в общем случае, выглядит как швейцарский сыр и описывается списком прямоугольников меньшего размера. Особенно наглядно этот процесс проявляется для событий DRAW/EXPOSE - когда приложение пытается себя перерисовать, графический драйвер получает только те фрагменты картинки, которые не перекрыты на экране другими программами (т.е. регионами).
Открытость
Когда речь заходит о создании новой графической системы, одна из основных проблем - как обеспечить ее привлекательность для потенциальных пользователей, которые (наверняка) уже пользуются какими-либо другими вариантами. Для организации, имеющей большой парк компьютеров (и соответствующее количество обученного персонала), решиться на переустановку программного обеспечения и переобучение пользователей не так-то просто. Тем более, если речь идет о системе "не для чайников".
Для решения этой проблемы разработчики стараются придать системе привычный (по крайней мере внешне) вид, снабжают ее on-line документацией и т.д. Однако всего этого недостаточно, если графическая система требует для своего функционирования совершенно другую ОС (многие пользователи и даже администраторы все еще приходят в ужас при одном упоминании UNIX, не говоря уже про QNX).
Разработчики системы Photon попытались решить и эту проблему нетривиальным способом, применив технологию инкапсуляции, что позволяет считать систему открытой. Для понимания этой технологии требуется некоторое знакомство с архитектурой системы
Рассмотренные выше идеи позволили спроектировать и реализовать очень необычную систему. Необычность архитектуры в свою очередь создает необычные возможности для разработчиков. В первую очередь это касается разработки сложных систем, выходящих за рамки традиционных приложений типа текстовых процессоров или электронных таблиц.
Графическое ядро
В традиционных графических системах нижний уровень представлен графическим драйвером. Все остальные модули и приложения пользуются его услугами. Поскольку драйвер работает с локальной видеосистемой, приложения ограничены локальным компьютером.
Несколько дальше идет система X Window, реализующая концепцию клиент-сервер применительно к графической системе. В ней существует понятие X-протокола, обеспечиваемого X-сервером (включающим в себя видеодрайвер). Клиенты (то есть приложения) могут пользоваться услугами любого доступного X-сервера, в том числе удаленного. Однако события могут возникать только там-же, где функционирует сервер.
Система Photon делает следующий шаг. Здесь видеодрайвер является таким же приложением, как и любая пользовательская программа. Все приложения и компоненты системы взаимодействуют между собой, получают информацию о событиях и реализуют свой сервис через единый унифицированный механизм регионов (агентов) и событий. Это свойство системы разработчики называют когерентностью. Абстракция регионов и событий поддерживается графическим ядром, которое и называется Photon. Поскольку транспортным механизмом для событий являетются сообщения сетевой ОС QNX, регион и владелец могут находиться на разных узлах сети. Регионы (как и положено агентам) служат не только для получения информации о событиях, но и для реализации собственных целей приложения. Например, для того чтобы что-либо нарисовать, приложение возбуждает событие типа DRAW, для перемещения объекта - событие DRAG, для перемещения мыши - PTR_MOVE и т.д., используя свой собственный регион в качестве источника события. Модуль, обеспечивающий соответсвующий сервис, просто устанавливает регион, чувствительный к соответствующему типу событий.
Таким образом, в системе Photon события, регионы и приложения могут быть произвольным образом распределены по сети.
Драйверы ввода/вывода
Под ними понимаются драйверы указательных устройств и клавиатуры (устройства ввода) а также видеодрайверы и драйверы принтеров (устройства вывода). Как было отмечено выше, драйверы являются обычными приложениями, так что их название говорит лишь об их функциональном назначении, но не об особом механизме работы. Технологически взаимодействие между ядром, драйверами и приложениями выглядит следующим образом.
Ядро при запуске создает два фиксированных региона - корневой (root) и регион устройств (device). Если представить себе пространство событий в виде аквариума, то корневой регион это сторона, противоположная наблюдателю (пользователю). Ближнаяя сторона соотвествует экрану монитора, а регион устройств находится посередине.
По принятому соглашению, драйверы устройств устанавливают свои регионы перед регионом устройств (ближе к наблюдателю), а прочие приложения - за ним. При этом драйверы ввода посылают события в сторону корневого региона, где они принимаются какими-либо приложениями и, возможно, трансформируются. Затем приложения посылают соответствующие события в обратную сторону, где они принимаются и обрабатываются драйверами вывода.
Необходимость в существовании формального региона устройств объясняется принятой технологией указания относительного положения регионов вдоль оси событий. При создании региона его положение задается неявно, через понятия предков, потомков и братьев. Потомок (child) всегда ближе к наблюдателю, чем предок (parent), а брат потомка может быть ближе чем он (brother-in-front), либо дальше (brother-behind), но в любом случае ближе предка. Регионы драйверов являются потомками региона устройств, а регионы прочих приложений - потомками корневого региона. Кроме того, благодаря региону устройств, ядро имеет возможность получать интересующие его события от драйверов до того, как они попадут к приложениям.
Менеджеры
Менеджеры также являются обычными приложениями, обеспечивающими стандартный сервис в тех случаях, когда он нужен. В состав системы входят менеджер окон PWM и менеджер "рабочего стола" PDM. Последнее понятие хорошо знакомо пользователям системы MS Windows 3.1, использующим что-либо более удобное, чем Program Manager в качестве менеджера рабочего стола. В системе X-Window можно выбирать менеджер окон. Photon позволяет отключить оба или использовать любую комбинацию. Например, менеждер окон является лишним в системе видеонаблюдения, работающей в полноэкранном режиме, а менеджер рабочего стола практически нужен только для системы разработчика.
Менеджеры также осуществляют свой сервис через специальные регионы, устанавливаемые в той-же области, где находятся регионы пользовательских приложений, то есть по формальным признакам они вообще ничем не отличаются от приложений.
Система Photon поставляется только в 32-х разрядной версии на 6 дискетах (4 runtime + 2 sdk) и устанавливается в течение 10 мин. Она способна автоматически опознать тип видеоадаптера и мыши и запустить соответствующие драйверы. Перезагрузок не требуется. В комплект поставки, помимо книжек, входит также on-line документация в формате HTML и соответствующая программа просмотра. Количество конфигурационных файлов можно пересчитать по пальцам и в них несложно разобраться.
Подобная скромность имеет простое объяснение - система не пытается объять необъятное. Она не предназначена и не претендует на роль универсальной системы для настольного компьютера домохозяйки. Вместо этого ее возможности сконцентрированы на главном - эффективно выполнять графические приложения в ограниченных ресурсах. Это однако не означает, что сервис полностью отсутствует. Структурно (и физически !) систему можно разделить на следующие элементы.
Ядро системы Photon
Этот компонент обязателен, но может быть запущен на другом узле сети (сервере). В его функции входит поддержка понятий регионов и событий, обработка событий типа DRAG а также регистрация пользователей при попытке установить соединение (login).
Произвольное количество приложений (в том числе драйверов) с любого узла (в том числе узла c другой ОС, связанного через протокол TCP/IP) может пользоваться услугами одного ядра. Координатное пространство, поддерживаемое ядром определено в границах от -SHORT_MAX до +SHORT_MAX по обоим осям, то есть по 65535 пикселов. По горизонтальной оси координаты растут традиционно - слева направо, а по вертикальной - сверху вниз, что позволяет использовать привычную систему координат на экране (начало координат по умолчанию соответствует левому верхнему углу экрана - см. далее).
Видеодрайверы Photon.XXX
Этот компонент также обязателен, причем на одном узле может быть запущено несколько драйверов (например, при наличии двух видеоадаптеров и мониторов). Драйвер получает все события типа DRAW, через регион, устанавливаемый ближе всего к наблюдателю и имеющий размер, соответствующий используемому видеорежиму (в пикселах). При запуске без параметров левый верхний угол региона (и, соответственно, экрана) будет иметь координаты (0, 0), в рамках графического пространства, но пользователь может явно определить положение экрана в пространстве событий.
Видеодрайвер обеспечивет реализацию основных графических примитивов (см. далее) и поддержку шрифтов. Курсоры также обеспечиваются видеодрайвером (программные или аппаратные), поскольку их образы хранятся в шрифтовых файлах. Внутренний формат представления цвета - 24 битный RGB, с возможностью аппаратно-независимого представления в формате HSV. Формат представления символов - мультибайтный, в соотвествии с ISO-10646-1.
На момент подготовки данной статьи поддерживаются и автоматически распознаются следующие типы видеоадаптеров:
Более того, в комплект поставки входит драйвер phinx, способный транслировать графические команды системы Photon в X-протокол. Это означает, что его можно запустить "поверх" запущенного драйвера X Window, а список адаптеров, поддерживаемых системой X Window исчисляется сотнями единиц (в том числе #9 Imagine 128 и Matrox MGA). Быстродействие конечно пострадает, но, по меньшей мере, будет не хуже чем VGA.
Заметим, что X-протокол может передаваться по сети типа TCP/IP, что позволяет пользователям системы X-Window запустить систему Photon в окошке, при наличии TCP-соединения с QNX-сервером, на котором работает ядро Photon.
Драйвер устройств ввода Pointer
Этот компонент требуется только для тех систем, в которых предполагается ввод информации. Pointer поддерживает клавиатуру, мышь и сенсорные экраны, причем он способен делать это без помощи стандартных драйверов консоли и последовательного порта ОС QNX, что позволяет снизить расход оперативной памяти. Регион Pointer’a устанавливается за регионом видеодрайвера и имеет точечный размер. Его положение совпадает с позицией мыши относительно левого верхнего угла экрана и определяет фокус ввода по умолчанию.
Когда мышь перемещается, Pointer посылает событие PTR_MOVE для региона устройств, который пропускает его дальше (для приложений) и уведомляет владельца (ядро), которое посылает событие DRAW от региона устройств обратно в сторону региона видеодрайвера - для перерисовки указателя мыши. Когда событие попадает в приложение, оно имеет возможность определить над каким объектом находится указатель и, при необходимости, поменять его внешний вид, путем соответствующего обращения к видеодрайверу. Аналогичным образом обрабатываются клавиатурные события.
На момент подготовки данной статьи поддерживаются и автоматически распознаются следующие типы указательных устройств (мышей и сенсорных экранов):
Этот компонент требуется только для тех систем, в которых необходима поддержка многооконного интерфейса. PWM реализует управление окнами в стиле OSF/Motif, хотя в ходе бета-тестирования декорации окон стали больше похожи на Windows 95. Кроме того, pwm поддерживает корневое меню рабочего стола и линейку задач.
Менеджер окон устанавливает регион непосредственно позади региона каждого приложения и чуть больше него размером. Эта "подложка" используется для реализации стандартных декораций окон. В результате, когда пользователь меняет размер окна, или перемещает его, соответствующие события принимаются и обрабатываются менеджером окон.
Еще одна важная функция менеджера окон состоит в переопределении фокуса ввода. По умолчанию фокус ввода принадлежит тому приложению, над регионом которого находится указатель мыши. Этот принцип известен давно, по менеджеру окон TWM в системе X-Window. Однако, это не всегда удобно, поэтому менеджер PWM имеет второй режим работы, в котором он отслеживает окно-владелец фокуса ввода, выбираемое щелчком мыши, и перенаправляет события от драйвера клавиатуры в него. Кроме того, можно задать метод визуализации перемещения окон (перемещение рамки окна или окна целиком) и другие опции.
Менеджер рабочего стола pdm
Этот компонент требуется только для тех систем, в которых необходима поддержка полноценного рабочего стола (то есть, система разработки). PDM реализует довольно простой механизм управления, не являющийся объектно-ориентированным. Он также неоднократно менялся в ходе бета-тестирования и, в конце концов, превратился в нечто, напоминающее горизонтально расположенный снизу MS Office 95 Shortcut Bar, только неподвижный и побольше размером.
Группы приложений в представляются в виде "закладок" и не могут быть иерархическими. Количество иконок, помещающихся в видимую часть закладки довольно мало, особенно при низком разрешении (впрочем, разработчику с низким разрешением и маленьким монитором вообще стоит поискать лучший способ убить время), так что их приходится прокручивать, что не очень удобно.
PDM также обеспечивает реализацию виртуального рабочего стола (3х3) и навигацию по его фрагментам, "обои", "хранители экрана" и управление режимом энергосбережения для соответствующих мониторов.
Драйвер принтера Photon.ps
Этот компонент требуется только для тех систем, в которых необходима поддержка печати. На момент подготовки данной статьи единственным поддерживаемым официально типом принтеров являются PostScript-совметимые устройства. Это пока самый большой недостаток системы, хотя она и не предназначана для офисных целей.
Кроме того, для системы QNX/Photon доступна бесплатная (GNU freeware) подсистема просмотра/печати GhostScript, первоначально разработанная для UNIX/X-Window, которая поддерживает лазерные, струйные и матричные принтеры распространенных моделей.
Средства сетевого взаимодействия
Еще два модуля, входящих в состав системы Photon - phditto и phrelay - обеспечивают реализацию специфических сетевых возможностей. Модуль phditto обеспечивает отображение произвольного фрагмента пространства событий на локальный фрагмент. Говоря по-русски, пользователь одного узла может видеть на экране (в окне) экран другого узла и даже работать с ним!
Очевидно, что поскольку на другом узле может быть свой пользователь, возникает потенциальное противоречие - оба могут пытаться работать одновременно.
Для разрешения этой проблемы в системе Photon предложена концепция группы ввода. Каждое событие имеет атрибут, содержащий номер группы ввода. Когда второй пользователь получает доступ к уже используемому экрану (то есть фрагменту пространства событий), ему назначается новая группа ввода. Графическое ядро отслеживает этот атрибут при анализе событий и обеспечивает их непротиворечивость. Например, если один из пользователей начал операцию перетаскивания окна (DRAG), то второй не сможет начать такую-же операцию с тем-же окном, пока первый ее не закончит. Кроме того, указатель мыши у второго пользователя будет выглядеть иначе.
Модуль phrelay - это сервер удаленного доступа, предназначенный для передачи событий между графическим ядром и удаленным клиеном, способным их обрабатывать и генерировать. Единственным стандартным клиентом является модуль phditto, остальные не входят в комплект поставки и продаются отдельно (см. Инкапсуляция).
Методы оптимизации
Одна из изюминок системы Photon заключается в интеллектуальности модуля phrelay - он не просто передает события, а пытается сделать это с максимально возможной эффективностью, с тем чтобы добиться приемлемой скорости даже на узкополосном канале связи, таком как телефонная линия. Для достижения этой цели он использует три метода - оптимизация протокола, кэширование и сжатие данных.
Как уже отмечалось выше, система X Window тоже позволяет осуществлять удаленный доступ, но достигается это ценой мегабайтов памяти на обеих сторонах и работает этот механизм приемлемо только на широкополосном канале (типа Ethernet). Доступ по модему практически нереален, поскольку X-протокол не эффективен при передаче по последовательному (узкополосному) каналу.
Система Photon не использует формальный протокол, что позволяет модулю phrelay осуществлять эффективную оптимизацию передаваемых событий. Структура событий сама по себе способствует снижению трафика - все события задаются в виде изменений относительно предыдущего (начального) состояния.
Каждый клиент сервера phrelay кэширует графические объекты, назначает им тэги-идентификаторы (tags) и передает их обратно серверу. Кроме того, при удалении объекта из кэша (по алгоритму LRU) клиент посылает уведомления серверу phrelay. Таким образом, phrelay "знает" состояние кэша у клиетов и при обработке перерисовки (события EXPOSE) передает им только те объекты, которых у них нет, причем он может делать это заранее, используя моменты низкой нагрузки.
Кроме того, при передаче событий phrelay выполняет сжатие данных по протоколу BPE (Byte Pair Encoding), характерному высокой степенью сжатия, низкими затратами на распаковку, средними затратами на упаковку и минимальными затратами на служебные данные. При передаче по последовательному каналу phrelay передает вместе с данными контрольные суммы (по алгоритму CRC-32). Клиенты могут проверять достоверность получаемых данных путем подсчета контрольных сумм и запрашивать повтор в случае ошибок.
Данный механизм был применен ввиду того, что phrelay может работать через последовательный интерфейс на низком уровне (без помощи протоколов SLIP/PPP, обеспечивающих сжатие данных и исправление ошибок), используя при этом полосу пропускания канала с максимальной эффективностью.
Описанные методы оптимизации позволили добиться серьезных успехов - удаленный клиент может работать с приемлемым временем реакции даже через модем со скоростью 19200 bps, которая достижима даже на плохих телефонных линиях, при наличии хорошего модема. Конкретнее, система Photon предоставляет два метода использования сетевых возможностей, описанных далее.
Технология Jump Gate™
Эта технология встроена на уровне прикладного интерфейса, благодаря чему она доступна автоматически для всех приложений. Суть ее состоит в том, что любое приложение можно "отправить" на другой узел, где работает другое графическое ядро. Иначе говоря, приложение совершает "гиперпространственный прыжок" - я затрудняюсь перевести название технологии более осмысленно, разве что "трамплин".
При этом код никуда не перемещается, передаются только регионы открытых окон. Видеодрайвер узла-адресата тут-же их отрисовывает и пользователь на том узле получает возможность поработать с принятым приложением. Менеджер окон узла-адресата выводит в зоне заголовка окна такого приложения специальную кнопку, нажав на которую можно вернуть его обратно. Реализация всей процедуры сопровождается модными визуальными эффектами - иконка Jump Gate "оживает", а окно приложения "затягивается" в нее, постепенно уменьшаясь в размерах, так что выглядит все очень впечатляюще.
Инкапсуляция
Эта технология реализуется с помощью модулей phditto, phrelay, phinx а также клиентов phrelay, поставляемых отдельно для различных операционных систем. Термин инкапсуляция применяется потому, что данная технология позволяет отобразить фрагмент пространства событий в окошке другой (или той-же самой) графической системы, возможно работающей с другой ОС.
Например, можно также запустить Photon внутри Photon’а, задав для первого режим 1024х768, для второго (внурти первого) 800х600, а для третьего (внутри второго) 640х480 и т.д. Эта возможность очень полезна для отладки менеджеров, драйверов и т.п.
Для системы UNIX/X-Window инкапсуляция обеспечивается драйвером phinx и протоколом TCP/IP. Можно запустить Photon в окошке системы X-Window на том-же самом компьютере, что дает возможность исполнять и отлаживать приложения для системы Photon, пользуясь привычными средствами среды X-Window.
Для систем Windows 3.x/95/NT и OS/2 Warp поставляется клиент phrelay, называемый Phindows, а для Macintosh анонсирован клиент Phintosh. Эти продукты также позволяют запустить Photon в окошке соответствующей системы, что дает возможность организациям, привыкшим или вынужденным работать с перечисленными системами, но нуждающимся в уникальных возможностях, обеспечиваемых системой Photon, установить один QNX-сервер и получать прямой доступ к приложениям Photon с любого узла, работающего под любой ОС.
На мой взгляд, такой подход представляется более эффективным и удобным, чем варианты вроде WABI или SoftWindows, когда пользователи должны жертвовать либо совместимостью, либо производительностью. Рецепт фирмы QSSL - возьмите лучшее из обоих миров - используйте Windows, там, где нужна Windows, используйте QNX, там где нужна QNX, используйте Photon где угодно.
Готовые приложения - традиционное слабое место всех новых систем, даже таких известных, как Windows NT, OS/2 или Solaris. Разумется, Photon не исключение, особенно учитывая разницу в масштабах фирм-разработчиков. В комплект поставки входит всего-лишь несколько утилит, демонстрационные программы и обычный набор игр.
Это неудивительно, учитывая, что система предназначена в основном для корпоративных клиентов, намеренных разрабатывать приложения самостоятельно. Однако, кое-что уже можно найти в виде бесплатных программ, например незабвенный DOOM, MPEG Player, CD Audio Player, Ghostview. Фирма QSSL также объявила о предстоящем выпуске для Photon’а WWW-клиента WebGazer, с поддержкой языка Java, а также новой оригинальной разработки - логического анализатора распределенных сетевых приложений Deja-ViewO .
Тем временем, многие независимые разработчики, выпускавшие продукты для среды QNX Windows и X Window, уже объявили о выходе версий для системы Photon. На нашей местной почве тоже кое-что растет - кроме очевидных средств поддержки национальной клавиатуры и шрифтов уже разработана по крайней мере одна промышленная система класса SCADA, предназначенная для облегчения задачи автоматизации производственных процессов. Короче говоря, лед тронулся.
Самое-же главное заключается в том, что система Photon действительно очень удобна для разработки новых приложений, особенно для программистов, знакомых с X Window. Помимо богатого набора виджетов, средства разработки включают довольно мощный визуальный генератор приложений, позволяющий получить код на языке C и делать с ним все, что угодно (см. далее AppBuilder).
Несмотря на то, что основной упор при разработке системы делался не на графическую мощь, а на масштабируемость и гибкость, Photon работает в общем случае практически с той-же скоростью, что и X Window для QNX, особенно при использовании акселерированных видеоадаптеров, поддерживающих аппаратный курсор, списки зон отсечения и двойную буферизацию.
Более того, фирма-разработчик постоянно совершенствует драйверы для системы Photon, так-что ее производительность выросла по-меньшей мере вдвое, за время бета-тестирования. В анонсированной версии Photon 1.1 видеодрайверы будут существенно переработаны для поддержки режима TrueColor (сейчас этот режим поддерживается только для адаптеров ATI Mach32) и увеличения производительности. Кроме того, будет расширен их ассортимент.
Для тестирования использовалась программа mpeg_player, портированная из среды X Window. Компьютерный видеоклип Reds Nightmare (O 1993, by IDDP IV, 1211 кадров, формат 320х200x256) на машине класса Pentium-90 с 16 Mb RAM и видеоадаптером S3 Trio64 PCI, проигрывается под управлением системы Photon со скоростью 10.37 кадров/сек. Под управлением системы X Window для QNX на той-же машине скорость составила 10.49 кадров/сек. Следует иметь ввиду, что версия X11R5 для QNX является самой быстрой версией X Window для архитектуры Intel x86 (350000 Xstones на ATI Mach64, 500000 Xstones на #9 Imagine 128). Даже Doom нормально работает на этой-же машине (в окошке) с разрешением до 640х480 (то есть, с учетверением пикселов), что следует признать весьма недурным результатом. Одним словом, начало хорошее.
Потенциальные сферы применения
Минимальный вариант системы, для которого достаточно ~400 Kb свободной памяти, состоит из графического драйвера, графического ядра Photon и драйвера Pointer. Еще минимум 512 Kb потребуется для ОС QNX, плюс некоторое количество памяти для приложений и можно получить графическую систему, работающую в 1-2 Mb памяти. По нынешним временам это как раз емкость очень дешевого чипа FLASH-памяти. Зная, что ОС QNX может быть записана во FLASH-память и поддерживает формат XIP (eXecute-In-Place), можно сконструировать множество необычных по возможностям компактных и недорогих графических устройств. Именно этот рынок и является основной целью разработчиков системы Photon.
Еще один очевидный вариант применения заключается в использовании уникальной технологии инкапсуляции для реализации визуальной связи между "черными ящиками", выполняющими задачи сбора данных и настольными системами под управлением Windows.
Кроме того, система имеет хороший потенциал развития и может с успехом быть использована там, где ранее требовалось применение дорогостоящей специализированной аппаратуры. Например, для реализации большого экрана мозаичного типа можно применить обычные компьютеры, связанные в сеть под управлением QNX. Единое графическое пространство будет обеспечено ядром Photon, а разделение его на фрагменты может быть достигнуто путем запуска соответствующего количества правильно спозиционированных графических драйверов. Самое интересное в этом варианте заключается в том, что экран может быть территориально расперделенным, поскольку сеть может быть сколь-угодно большой.
Представьте систему слежения за подвижными объектами, в которой есть несколько операторов, отвечающих за определенные участки территории. Если у каждого из них есть монитор с фрагменом единого графического пространства, то при выходе объекта из зоны одного оператора, он автоматически появится на мониторе другого. При этом операторы могут видеть экраны друг друга и даже перемещать окна между собой.
С другой стороны, может оказаться полезным возможность наложения графических драйверов на один участок пространства. Например, таким образом можно создать тренажерный класс, в котором все обучаемые видят на своих экранах то, что делает инструктор.
Наконец, по мере появления готовых приложений, например класса SCADA, может оказаться что использование системы Photon будет выгоднее или эффективнее традиционно применяемой для этого системы X Window. Осталось только подождать.
Если графическая система не имеет большого количества готовых приложений, то она должна, по крайней мере, обеспечивать хорошие возможности для разработки. С этой точки зрения с системой Photon все в порядке. Удачная модель программирования в сочетании со средствами быстрой разработки приложений обещает, что в недалеком будущем дефицит приложений будет ликвидирован.
Прикладной интерфейс
Концепция прикладного интерфейса Photon практически совпадает с системой X Window. В целом это удачный выбор, поскольку он позволяет использовать объектно-ориентированный подход в рамках языка C. Этот язык имеет ряд существенных недостатков, как теоретических, так и практических, но он гораздо проще для освоения, чем С++. Кроме того, существует огромное количество программного обеспечения для среды X Window и значительное количество программистов, которым несложно перенести их приложения в систему со схожим прикладным интерфейсом, чему уже есть несколько хороших примеров.
Модель программирования X Window достаточно хорошо известна, поэтому нет смысла излагать ее здесь вновь. Тем не менее, система Photon не является эквивалентом X Window, поэтому в ее API и средствах разработки есть существенные отличия, которые будут кратко проанализированы далее, исходя из пердположения, что читателям знакомы по меньшей мере понятия "widget" и "callback".
Взаимодействие с графическим ядром
Наличие в системе графического ядра существенно меняет структуру прикладного интерфейа, а именно, в ней появляется более низкий уровень, чем базовая графика. Строго говоря, называть его более низким можно лишь условно, поскольку он существует скорее в другом измерении, которому нет полного эквивалента в традиционных системах. Как отмечалось выше, ядро отвечает за поддержку абстракций регионов и событий, а также за стандартную обработку событий типа DRAG.
Для обеспечения доступа приложений к этому уровню, API системы Photon предусматривает специальный класс функций, позволяющих получать общую информацию о графической системе, создавать и удалять регионы, получать информацию о регионах и изменять их характеристики, а также ицициировать и получать события.
Вообще говоря, программист может и не иметь дела с этим уровнем API, поскольку вышележащие уровни скрывают его, предоставляя большинство услуг, необходимых для типичных приложений. Тем не менее, обращение к данному уровню будет необходимым для написания собственных драйверов, менеджеров или других приложений с нестандарными функциями или пользовательским интерфейсом. Иногда программисту может понадобиться более полный контроль за обработкой событий, чем тот, что предоставляется стандартными методами.
Регионы играют роль агентов приложений не только в смысле получения событий, но и в смысле их инициации. Например, вывод на экран чего-угодно реализуется в системе путем посылки события DRAW от региона, представляющего приложение, в сторону региона устройств (и, соответственно, графического драйвера). Вывод графики всегда назначается в какой-либо регион, т.е. процесс не может рисовать за пределами регионов, которыми он владеет. Аналогично, приложение не может получать события, происходящие за пределами чувствительных регионов, которыми оно владеет.
Высокоуровневый интерфейс обеспечивает создание регионов-подложек для каждого окна приложения, но иногда может потребоваться нестандартный вариант - например вывод на экран "обев". Для этого приложение просто создает регион размером с экран, непосредственно перед корневым, и выводит в него картинку. Таким образом, все остальные приложения будут выводить свою графику на полученном фоне.
Для получения событий приложение может применять три метода: синхронный (стандартный), асинхронный и опрос. Асинхронный метод позволяет приложению не блокировалься при отсутствии сообщений, что бывает иногда необходимо, при написании процессов-серверов. Метод опроса, вероятнее всего, будет полезен при написании драйверов.
Стандартная (отключаемая) обработка событий типа DRAG, заключается в визуализации процедуры (резинка) и, возможно, уведомлении процессов, участвующих в ней, что дает им дополнительные возможности по интерпретации и визуализации процедуры.
Базовая графика
Программистам X Window известно, что при необходимости вывода графики приходится обращаться к библиотеке Xlib. Этому уровню в системе Photon соответствует класс базовых графических функций. Основное отличие заключается в отсутствии четко определенного формального протокола, подобного X11.
Большинство функций выполняет одну из двух ролей - создание и определение графического контекста или вывод графических примитивов. Графический контекст включает в себя текущие значения основных параметров выводимых графических примитивов (цвет, толщина линий, маска псевдосмешения и т.п.), в том числе и номер текущего региона. Набор графических примитивов достаточно богат, хотя и не настолько, как в X Window. Туда входят линии, полигоны, прямогольники, эллипсы, дуги, кривые Безье 3-го порядка, битовые плоскости, цветные растры в разных форматах, регулярные структуры типа "решетки", текст и некоторые другие объекты.
В рамках данного уровня предусмотрен также механизм использования разделяемой памяти, исключающий излишнее копирование данных между приложением и графической подсистемой, при выводе битовых плоскостей и растров.
Необходимость в обращении к данному уровню возникает либо при разработке новых виджетов, либо при необходимости использования в приложении пользователской графики. В последнем случае обычно применяется комбинирование, то есть пользовательская графика выводится в рамках специального виджета класса RAW, обеспечивающего стандартизованный интерфейс и поведение полученного объекта. В задачу программиста при этом входит написание функции, отвественной за перерисовку содержимого, с сохранением и последующим восстановлением графического контекста.
Набор виджетов
Данный уровень является основным для программистов, и не содержит больших теоретических неожиданностей. Он эквивалентен уровню Xtoolkit в системе X Window, но практических различий довольно много. Они касаются как иерархии виджетов, так и их состава, именования ресурсов и соглашений об интерфейсах. Что-же касается функций, то многие из них отличаются только префиксом (Xt……../Pt..). Как отмечалось выше, система Photon обеспечивает пользовательский интерфейс в стиле OSF/Motif, однако это касается только внешнего вида и поведения приложений, в то время, как стандарт Motif определяет также набор виджетов и функций, дополняющий Xtoolkit.
Иерархия виджетов в системе Photon сильно упрощена, что несколько упрощает ее изучение. Состав виджетов также существенно отличается. Например, отсутствуют такие важные виджеты, как CompoundString и ScrolledText, но есть совершенно другие виджеты MultiText и ScrolledArea, способные их заменить. Вместо неудобного виджета OptionButton используется привычный пользователям ComboBox.
Поддержка "отрывных" меню (Tear-Off) пока отсутствует, но обещана в будущем. Еще один недостаток заключается в отсутствии в виджетах полноценной поддержки клавиатуры в соответствии с CUA, однако и это упущение будет ликвидировано в версии 1.1.
Приведенная здесь полная иерархия виджетов системы Photon, позволяет оценить степень полноты прикладного интерфейса. Описание всех виджетов выходит за рамки данной статьи, но для программистов и названия говорят сами за себя.
В то-же время, фундаментальные концепции сохранены, включая понятия базового и дочерних окон, диалогов, контейнеров и управления геометрией, поэтому, несмотря на описанные различия, програмы для X Window и Photon очень похожи.
В версии 1.1 будет добавлено большое количество новых виджетов, в том числе PtHTML (отображение текста в формате HTML), PtTerminal (терминальное окно), PtFileSelector (в настоящее время реализован в виде модуля AppBuilder), а также новые виджеты, предназначенные для визуализации динамических данных (группа RealTime).
Особенности техники программирования
Разработка приложения в целом сводится к инициализации требуемой структуры виджетов, после чего приложение переходит в цикл приема сообщений. Концепция прикладного интерфейса требует, чтобы для всех виджетов, предусматривающих возможность реакции на события, были описаны соответствующие callback-функции. Прием и анализ сообщений, с вызовом соответствующей функции обработки реализуется обычно с помощью функции PtAppMainLoop. Эта функция реализует довольно гибкую схему обработки, которая включает возможность приема и обработки посторонних сообщений а также использование пауз между сообщениями.
Основная проблема, с которой сталкиваются разработчики в графических системах, заключается в том, что прием и обработка сообщений, а также перерисовка экрана выполняются обычно одной и той-же нитью. Иначе говря, пока callback-функция не вернет управление, приложение не может реагировать на поступающие события, в том числе выполнять перерисовку. Для решения проблемы можно использовать различные методы, основные из которых это использование фоновых процедур и разделение нитей (например, путем порождения нового процесса, или использования специального процесса-сервера).
Фоновые процедуры (Working Procedures) могут применяться в тех случаях, когда обработка определенных событий может быть легко разделена на небольшие по длительности итерации. Обработка при этом выполняется на фоне приема сообщений, то есть в паузах между ними. В тех-же случаях, когда применить такой подход невозможно, наиболее целесообразным вариантом может быть порождение дочернего процесса или нити.
В принципе, приложение можно разделить на две логически независимые части - интерфейсный модуль, обеспечивающий взаимодействие с пользователем и перерисовку виджетов, а также модуль семантической обработки, взаимодействующий с интерфейсным модулем через механизм обмена сообщениями. Такой подход, кроме радикального решения описанной проблемы, значительно упрощает перенос приложений на другие платформы или под другие графические интерфейсы.
Еще один нюанс заключается в отсутствии в системе Photon формальных протоколов для операций типа Drag’n’Drop и обмена данными через Clipboard. DRAG-протокол в системе X-Window обеспечивает реализацию пользовательских визуальных эффектов, типа Drag-Over, Drag-Under и т.п. Возможности для реализации визуальных эффектов в системе Photon существуют, однако нет стандартизованного механизма их описания. Задание произвольного пользовательского курсора возможно лишь через недокументированный интерфейс на уровне базовой графики, стандартные же методы позволяют выбирать курсор только из предопределенного списка. Таким образом, при разработке программ, реализующих механизм Drag’n’Drop, программисту придется полагаться на свой вкус. Что касается операций через Clipboard, то этот механизм вовсе не предусмотрен, так что программисты могут проявить свою фантазию.
Неожиданностью может оказаться также кодировка символов, особенно для разработчиков в не-англоязычных странах. Все символы с кодами старше 127 должны при выводе представляться в виде мультибайтового потока, в соответствии со стандартом ISO-10646-1. Этот стандарт предусматривает кодирование символов национальных языков последовательностями переменной длины (от 1 до 6 байт). Достоинство стандарта заключается в совместимости представления набора символов Latin-1 с 7-битной кодировкой ASCII и возможности перемешивания в одном потоке последовательностей разной длины (и разных языков). Например, символы русского языка необходимо преобразовывать в двухбайтовые последовательности перед выводом и обратно - после считывания текстовых данных из виджетов.
Генератор приложений AppBuilder™
Наличие этой программы является самой хорошей новостью для потенциальных разработчиков, поскольку она соединяет в себе мощное средство прототипирования с генератором кода и редактором ресурсов. Разработка визуального макета довольно сложного приложения может быть выполнена с ее помощью за один рабочий день, причем макет будет функциональным с точки зрения интерфейса, то есть связи между окнами и диалогами будут действовать. Кроме того, AppBuilder (ver. 1.1) предоставляет удобный механизм поддержки мультиязычных приложений и некоторые средства переноса приложений из среды QNX Windows.
Приложение, с точки зрения программы AppBuilder, состоит из модулей, являющихся единицами хранения виджетов. Иначе говоря, виджет всегда перетаскивается в какой-либо модуль. Тем не менее, имена виджетов должны быть уникальны в пределах всего приложения. Модули принадлежат к одному из следующих типов:
| Window | базовое окно или диалог, допускающий множество экзепляров |
| Dialog | дочернее окно или окно, существующее в одном экземпляре |
| Menu | всплывающее или выпадающее меню |
| Icon | иконки базового окна (большая - для PDM, маленькая - для PWM) |
| Picture | хранилище виджетов для динамической загрузки из приложения |
| Other | модальные диалоги (на данный момент - FileSelector и Message) |
При создании нового приложения автоматически создается модуль базового окна, остальное - дело программиста. Модули типа Window, Dialog и Icon построены на основе соответствующих виджетов, поэтому их описание и управление ими выполняется стандартным образом. Модули типа Other реализованы в виде функций, поэтому они изображаются в виде образцов, хотя механизм управления ими для унификации выполнен в стиле виджетов (т.е. через ресурсы).
Модули типа Menu, как ни странно не основаны на непосредственном использовании виджета PtMenu. Более того, для их описания и управления применяются нестандарнтые методы, что вносит некоторую хаотичность в довольно стройную концепцию API. Описание меню выполняется через специальную структуру данных (и специальный редактор), а для доступа к этим модулям приложение должно пользоваться специфическими функциями, недоступными приложениям, построенным без использования программы AppBuilder. К сожалению, эти функции недостаточно тщательно продуманы, в результате чего, для латания образовавшихся дыр, программистам придется обращаться к недокументированному закрытому интерфейсу, что противоречит принципу инкапсуляции данных и создает потенциальные проблемы совместимости приложений с будущими версиями системы.
Модули типа Picture предоставляют механизм динамического порождения виджетов по шаблонам и обычно используются для хранения многократно используемых ресурсов. Для их использования приложение также должно использовать специальные функции, доступные только программам, построенным с помощью AppBuilder.
После описания всех модулей, средствами AppBuilder можно описать также статические связи. Например, если после нажатия какой-либо кнопки должен появиться определенный диалог, то эту зависимость можно описать и она будет вставлена в генерируемый код. Таким образом, можно описать поведение всех меню и кнопок.
Реализуется эта возможность путем введения в виджеты специального типа ресурса, называемого связью (link-callback). Связь может указывать на модуль любого типа и может описывать позицию модуля на экране, а также функцию инициализации модуля. Наличие этой функции, вызываемой до и/или после реализации модуля, позволяет выполнить настройку модуля, в соответствии с текущим состоянием программы. В частности, функция может отменить реализацию модуля, превращая тем самым связь в псевдо-динамическую.
Самой ценной особенностью механизма связей является возможность создания "висячих связей" (internal links), то есть связей, указывающих на какой-либо модуль с определенным контекстом реализации, но неопределенной точкой вызова. Такой модуль легко реализуется из программы, вызовом всего одной функции.
На долю программиста остается (всего лишь) написание собственно функциональной части приложения, так что никаких чудес здесь нет. Однако, описанная технология все же лучше, чем программирование приложения с нуля или даже средства типа UIL, применяемые в X Window.
Некоторые проблемы вероятно возникнут у разработчиков, желающих использовать язык C++. Все библиотеки и заголовочные файлы совместимы с этим языком, однако этого не скажешь о программе AppBuilder - она не сможет правильно сгенерировать прототипы и Makefile. Проблема заключается в том, что функции-методы рассматриваются так-же, как обычные, то-есть для них формируются прототипы, помимо тех, что уже описаны в классе, что вводит компилятор в растерянность. Кроме того, вся система довольно жестко орентирована на расширение имени ".c". Решение заключается в модификации файла Makefile, с тем чтобы исключить из процесса генерации прототипов файлы с описанием методов, а также переопределить вызов компилятора. После этого следует давать файлам C++ имена с расширением ".c" и можно работать.
Версия AppBuilder 1.1, кроме того, предоставляет очень удобный механизм для разработки мультиязычных приложений. Суть его состоит в том, что AppBuilder может сгенерировать базу данных, содержащюю все использованные в интерфейсе текстовые строки. Для сообщений, выводимых из программы динамически, можно применить манифесты, ссылающиеся на строки, записанные в модуле типа Picture, что позволит включить их в базу языков. Затем, через специальную программу Language Editor, можно создать произвольное количество трансляций каждой строки на разные доступные языки. Перед запуском программы пользователь может определить специальную переменную окружения, указывающую какой из определенных языков она должна использовать.
Таким образом, можно иметь один и тот-же исходный текст для всех национальных версий приложения, что должно быть по-достоинству оценено разработчиками, хотя-бы раз имевшими дело с поддержкой нескольких версий одной и той-же программы.
На мой взгляд, первое, что бросается в глаза - это некоторая сырость системы. Стоит однако учесть, что система основана на совершенно новых идеях и версия 1.0 была выпущена лишь полгода назад. Если вспомнить, какой путь проделала та-же MS Windows, пока дошла до разумного состояния (3.1), то можно простить разработчикам этот грех (пока).
Следует признать, что принципы, заложенные в систему, имеют и обратную сторону - наличие ядра означает наличие дополнительного посредника между приложением и аппаратурой, что неизбежно влияет на производительность графики. Тем не менее, производительность оказалась достаточно хорошей.
Поддержку видеоадаптеров также
следует признать недостаточной, но есть надежда на скорое изменение ситуации. С
приложениями тоже пока плохо, но зато их легко разрабатывать, так что бочка
меда, в целом, все-таки перевешивает ложку дегтя.
Изменения в версиях 1.11 и 1.12
После написания оригинальной версии статьи прошел год и уже можно делать выводы о направлении и скорости развития системы Photon. Хорошая новость заключается в том, что и направление и скорость выглядят многообещающе.
За прошедший год вышло три новых версии системы - 1.10, 1.11, 1.12, содержащие ряд существенных улучшений и архитектурных изменений. Вот лишь наиболее важные из них:
Matrox Millenium
ATI 3D Rage
II/Pro
IBM XGA
Trident
9470
Tseng
Cyrix
универсальный драйвер видеоадаптеров класса VESA
2.0
PtHTML,
PtTree,
PtDivider
PtMenuBar,
PtGrid
PtFontSel
RtProgress
PtPrint
PtFilleSel
PtNumericInteger
PtNumericFloat
File Manager
CD Player
Audio Player
Calculator
Personal Information Manager
Internet Suite (Web-browser, E-mail и Usenet News);
| ©1999 by Nigl Mail to: [email protected] Last update 99-356 |
.gif){kind=small}