Я бы сказал про этот пост - все это наверно прикольно но в этой теме ПОЛНЫЙ OFFTOP.Сообщение от CodeMaster
Про microwindows - терзают меня смутные сомнения. С одной стороны концептуально сам код клиентской программы под win16 мало чем отличается от похожей проги под X-ы или GEM или просто графического демо обсуждавшегося в соседней ветке: http://www.z80.eu/gsx.html
Т.е. идея = клиентская программа имеет некие процедуры создания GUI элементов, которые состоят из вызовов создающих графические примитивы или отдельные элементы (как кнопки например). Ну в предлагаемом подходе сама библиотека рисующая эти примитивы и элементы будет на стороне графического проца и занимать памяти не будет.
В данном подходе мне ненравиться то что сама библиотека графики расширению не подлежит и если надо нарисовать шото более "другое" чем стандартное то это ляжет на плечи клиентской проги как с точки зрения памяти так и скорости (прийдется использовать пачки вызовов рисования более простых примитивов).
Альтернативой такому подходу думаю может быть графический язык типа forth-a на котором клиент заранее задает всю свою графику и хранит на внешнем носителе в виде "макросов". Потом перед использованием "загружает" эти "макросы" на "графический терминал" и вызывает появление нужных кусков изображения в нужном месте в нужное время своими дальнейшими вызовами этих макросов.
Ну и хочу напомнить, что с этими двумя подходами, когда часть требуемой вычислительной мощи будет передана "графическому терминалу" нужно быть осторожными (!) чтобы неперестараться. Как было указанно в соседней ветке - такое устройство будет интересно только в том случае если его железо по интеграции вполне могло бы быть изготовленно во времена рассвета PDP-11 (1975...1984 года). А иначе получим гипертрофированного монстра типа плата PDPPC с ВМ3 установленная в современный x86 и рисующая графику на новейшем nVidia адаптере с CUDA и всем остальным навесом
Ответить с цитированием