Основные концепции графического программирования в САПР. Краткий обзор (САПР)

Термин программирование на компьютере (computer programming) раньше озна­чал написание «сочинения» на языке компьютерных команд в соответствии с предопределенными правилами грамматики. В ответ на вводимые числа выпол­няемое «сочинение» порождало ожидаемые числа и символы на терминале или в файле данных. В наши дни на входе и выходе «сочинений» все чаще находит­ся графическая информация. Такое программирование называется графическим (graphics programming), а область его применения — компьютерной графикой (computer graphics}.

Помимо основного программного обеспечения, необходимого для обычного про­граммирования (операционная система, редактор и компилятор), графическое программирование требует наличия специальных графических программ. Гра­фические программы делятся на два класса: драйверы устройств и графические библиотеки.

Драйвер устройства может рассматриваться как набор аппаратно-зависимых ко­дов, непосредственно управляющих процессором данного графического устройства.

Примерно то же самое можно сказать об ассемблере, конкретный вид которого может выпол­няться только на процессорах одной и той же модели. То же происходит, если графическая программа использует драйвер устройства непосредственно (рис. 5).

Такую графическую программу при переходе на другое графическое устройство придется переписывать с использованием новых команд драйвера. Более того, команды драйвера устройства весьма примитивны, поэтому такая программа была бы очень длинной, если бы она должна была решать какую-либо сложную задачу. К тому же программа эта получилась бы плохо читаемой.

Программисты предпочитают писать программы на языках высокого уровня. Графическое программирование не могло стать исключением, особенно если представить все неудобства, связанные с использованием команд драйвера низ­кого уровня. Поэтому с графическими устройствами стали поставляться библио­теки, получившие название графических (graphics libraries). Графическая библио­тека, как, например, и математическая, представляет собой набор подпрограмм, предназначенных для решения определенных задач. Конкретная подпрограмма может изображать на экране прямую, круг или иной объект. Графическая биб­лиотека основывается на командах драйвера устройства (рис. 6). Каждая под­программа создается с использованием поддерживаемого набора команд драй­вера. Например, подпрограмма, изображающая круг, может быть составлена из отдельных команд драйвера, рисующих на экране точки или короткие отрезки.

Рис. 6 Использование графической библиотеки

Подпрограммы графической библиотеки могут использоваться точно так же, как подпрограммы математической. Нужная подпрограмма вызывается из основной программы аналогично тому, как вызываются функции синуса и косинуса, когда программисту требуется вычислить их значения. Одна из проблем использова­ния подпрограмм графической библиотеки связана с тем, что их названия и спо­собы вызова (входные и выходные аргументы) у каждой библиотеки свои. Это не создавало бы трудностей, если бы одна графическая библиотека могла рабо­тать со всеми существующими устройствами, что теоретически было бы возмож­ным, если бы все существующие драйверы устройств поддерживали ее. Однако по некоторым причинам производители программного обеспечения не хотят или не могут создать графическую библиотеку, которая могла бы работать со всеми драйверами, а потому у каждой библиотеки имеется свой круг поддерживаемых драйверов. Следовательно, такая библиотека может работать лишь с ограничен­ным набором графических устройств, а графические программы, рассчитанные на работу со множеством устройств, приходится переписывать с использованием нескольких библиотек.

Чтобы обойти эту проблему, разработчики графических библиотек могли бы использовать одинаковые наборы подпрограмм с одинаковыми названиями, аргументами и возможностями. (На практике каждая подпрограмма реализует­ся разработчиками по-разному.) Тогда графические программы не требовали бы изменения на уровне исходного кода даже при изменении графических уст­ройств. Одним из примеров такого подхода является графическая система CORE, предложенная в 1977 г. группой SIGGRAPH (Special Interest Group on Compu­ter Graphics) Ассоциации вычислительной техники (Association for Computing Machinery — ACM). Однако графическая система CORE не предоставляет дос­таточного набора команд для использования всех возможностей растровых уст­ройств, потому что эти устройства не были широко распространены во времена разработки системы. Примерно в то же время Международная организация по стандартизации (International Standards Organization — ISO) разработала систе­му графического ядра (Graphics Kernel System — GKS). GKS считается стандар­том в двухмерной графике, а позже эта система была расширена до GKS-3D с поддержкой трехмерной графики.

И у CORE, и у GKS есть определенные недостатки в отношении динамическо­го отображения и гибкого взаимодействия с пользователем. Поэтому организа­ция ISO предложила еще один стандарт, получивший название Иерархическая система программирования интерактивной графики (Programmer's Hierarchical Interactive Graphics System — PHIGS). Этот стандарт стал стандартом де-факто для большинства графических рабочих станций. Затем он был расширен и полу­чил название «расширение PHIGS для X» (PHIGS extension to X — РЕХ), пото­му что в него были включены функции работы с окнами системы X window. Гра­фические программы, написанные на РЕХ, в сетевой среде могут использоваться независимо от типа рабочей станции. Это достоинство было унаследовано от системы X window, о которой будет коротко рассказано в конце главы. Коммер­ческая графическая библиотека OpenGL развивалась независимо от организа­ций по стандартизации, однако с течением времени она набирает все большую популярность благодаря гибкости в управлении рабочими станциями и персо­нальными компьютерами в сетевой среде. OpenGL — расширение графической библиотеки GL (фирменной графической библиотеки для компьютеров Silicon Graphics). Благодаря популярности компьютеров Silicon Graphics в областях, связанных с компьютерной графикой, библиотека OpenGL постепенно приобре­тает статус графического стандарта де-факто.