Псевдодисплейный файл преобразованный

При каждом приложении различных преобразований к одному и тому же элементу псевдодисплейного файла может генерироваться совершенно иная последовательность дисплейных команд. Рассмотрим пример, приведенный на рис. 8.4. Здесь использован лишь один символ, но вследствие применения различных масштабных коэффициентов, а также алгоритма отсечения все пять высвеченных на экране привязок изменены различными способами. Поэтому необходимы пять различных кодовых последовательностей. [c.156]

Иногда желательно сохранить тот же уровень структурности в преобразованном дисплейном файле. Существование структуры облегчает замену отдельных частей дисплейного файла, соответствующих измененным секциям псевдодисплейного файла. Это позволяет также использовать традиционный метод указания элемента с помощью светового пера. Однако было бы ошибкой полагать, что всегда следует сохранять всю структуру псевдодисплейного файла. Часто привязки используются в псевдодисплейном файле скорее для экономии памяти, чем для описания структуры изображения. Привязки такого рода нет необходимости представлять в структуре преобразованного дисплейного файла. Как будет показано ниже, часто можно обойтись весьма простой конструкцией преобразованного дисплейного файла. [c.157]

Структуры на рис. 8.6 эквивалентны в том смысле, что каждая привязка в псевдодисплейном файле генерирует обращение к той же подпрограмме в преобразованном дисплейном файле. [c.157]

Хотя можно объединять базу данных и псевдодисплейный файл в единую структуру графических данных, в большинстве случаев все же необходимо преобразовывать эти данные программным путем (рис. 8.8, в). В исключительных случаях, когда дисплейный процессор может выполнять все преобразования, заданные в структуре графических данных, компиляция дисплейного файла сокращается до процесса, показанного на рис. 8.8, г. Пятый и несколько иной подход с использованием процедур отображения рассматривается в разд. 8.8 данной главы. [c.158]

На этом рисунке изображены все процессы, необходимые в системе, выполняющей поворот. Программа трассировки просматривает псевдодисплейный файл и передает все данные о преобразованиях программе совмещения, а все графические данные — одной из двух используемых программ преобразования и отсечения. Если поворот отсутствует, то данные получает программа отсечения и кадрирования в противном случае данные поступают в программу матричного преобразования и отсечения. Обе эти программы передают свои результаты одному и тому же генератору дисплейного кода. [c.164]

Программа трассировки является самым простым из четырех процессов в системе преобразования. Она должна уметь следовать по структуре псевдодисплейного файла и распознавать различные типы встречающихся данных. Графическая информация передается соответствующей программе преобразования и отсечения, а параметры преобразования — программе совмещения, в которой они комбинируются с уже действующими параметрами. [c.167]

После перевода координат конечных точек в единицы растра дальнейший процесс генерации кода идентичен компиляции дисплейного файла. Например, можно построить сегментированный преобразованный дисплейный файл таким образом, чтобы можно было заменять один его сегмент без преобразования всего псевдодисплейного файла. Однако необходимо тщательно продумать взаимосвязь между результирующей структурой дисплейного файла и структурой псевдодисплейного файла. [c.172]

Если решено сегментировать дисплейный файл, то это можно осуществить двумя основными методами. Первый заключается в задании псевдодисплейного файла в виде отдельных подконструкций, каждая из которых имеет собственные окно и поле индикации, заданные на высшем уровне. Эти подконструкции (рис. 8.20, а) аналогичны основным записям структурированного дисплейного файла. В преобразованном дисплейном файле для каждой подконструкции формируется соответствующий отдельный сегмент (рис. 8.20, б). При необходимости изменения одного элемента подконструкции приходится повторно генерировать весь сегмент. [c.173]

Такая организация системы, несмотря на широкое использование, далеко не идеальна. Прежде всего она очень неэффективна с точки зрения использования памяти, поскольку информация, появляющаяся на экране, представляется три раза один раз в базе данных, еще раз в псевдодисплейном файле и, наконец, в преобразованном дисплейном файле. Во избежание такого трехкратного представления были предложены другие способы организации системы, показанные на рис. 8.8, в которых устраняются преобразованный дисплейный файл (рис. 8.8, а), исходная база данных (рис. 8.8, в) или и то и другое (рис. 8.8, г). [c.175]

В результате обращения к этим макрокомандам в псевдодисплейном файле формируется основная копия, подобная приведенной на рис. 8.23. Можно добавить несколько привязок этой основной копии, каждую с собственным преобразованием. Для осуществления этого [c.175]

Когда программа трассировки интерпретирует псевдодисплейный файл, она обрабатывает каждую из привязок, устанавливает параметры преобразования и затем просматривает основную копию символа. Поскольку информация в основной копии чисто графическая, она передается непосредственно программе преобразования и отсечения, которая получает следующую информацию [c.176]

При реализации метода процедур отображения предполагается минимальное изменение синтаксиса языка и, следовательно, транслятора необходимо только добавить процедуры для выполнения операций переноса, отсечения, совмещения преобразований и ввести генератор дисплейных кодов. Для обеспечения подобных возможностей с помощью макрокоманд необходимо написать компилятор псевдодисплейного файла, подпрограмму слежения за текущей позицией луча, а также все элементы системы преобразований. Кроме того, нужно предусмотреть, чтобы система распределения свободной памяти обеспечила потребности компилятора псевдодисплейного файла. Однако при этом нельзя вносить никаких изменений в язык. Если для работы системы не нужны какие-либо преобразования, то может использоваться более простой компилятор дисплейного файла, в котором функции графических макрокоманд ограничены формированием набора графических примитивов. В этом случае их применение является тривиальной задачей. Поскольку выше были подробно рассмотрены задачи макрокоманд при генерации дисплейного файла, то в этой главе только подведены итоги по вопросу о [c.368]

Представляет интерес изучить влияние размещения разделительных линий в том или ином положении. Фоли [93] опубликовал подробное исследование этой проблемы, а также проблемы выбора полосы пропускания для канала передачи информации между центральным процессором и терминалом. Его подход состоял в разработке математической модели графической системы с разделением времени и в использовании этой модели для оптимизации стоимости системы и скорости реакции. При попытке оптимизации указанных параметров легко ошибиться, если не учесть некоторых важных аспектов. Один из них состоит в следующем при любом делении системы оно должно быть возможно более простым и четким, что позволяет уменьшить сложность программного обеспечения. Обречена на неудачу попытка разместить два компонента на терминале, если компонент, расположенный между ними, находится в центральном процессоре. Например, нельзя использовать центральный процессор для преобразования псевдодисплейного файла, который хранится на терминале. Аналогично этому следует быть в высшей степени осторожным при использовании некоторых типов структур графических данных, например структур двойного назначения в системе, где терминал отделен от центрального процессора. В этом случае возникают противоречивые желания поместить эту структуру как в центральный процессор для обеспечения возможности ее использования прикладной программой, так и в терминал, чтобы воспользоваться ею для регенерации дисплея. Этот аспект не был принят во внимание некоторыми разработчиками сателлитных систем [43, 58]. [c.393]

Энциклопедия по машиностроению XXL

Оборудование, материаловедение, механика и ...