Собственно сабжНажмите для просмотра прикрепленного файла

Нормально сформулируйте свою мысль. В файле ничего аномального нет.

Естественно , полагаю это первый результат работы. 

Почитал. Понравилось. Молодец.

Мысль такова: вместо того, чтобы использовать полноценную ОС вместе с быстрой файловой системой на быстром контроллере, были сделаны костыли в виде предварительной подготовки данных на ПиСи, хранения фрагментов изображений в промежуточном формате ( pcx - компромисс между объемом и скоростью декомпрессии в условиях недостаточного быстродействия), фонового разворачивания фрагментов экранов и прочее....
По большому счету, тупик.
Тем не менее получили приемлемые результаты по скорости интерфейса пользователя, отвращения нет, надеемся, что найдем еще применения, где такое решение пригодится.

Не хотите ли вы сказать, что на таком мощном ARM-е труд негров за фотошопом эффективнее нормальной GUI c симулятором ?

В общем то да. Можно свалить подготовку интерфейса пользователя на тупого дизайнера или даже заказчика!
Но на самом деле о фотошопе говорить практически не приходится. Фотошоп предполагает сложные картинки, длинноногих девчонок. А если натолкать сложные картинки, то сразу файловая система забирает вагон времени.
Хорошо Вам на ARM9 хвалиться GUI с масштабированием окон

Резервы быстродействия на самом то деле есть (в файловой системе, в инициализации памяти), но руки не дошли их исчерпать.

На рисунке, гы-гы, однако баг: обороты 850, а скорость 100. А если втопить на 6500 об/мин, то стрелку спидометра сколько раз можно будет "уложить"?

Это, кстати, очень хороший вариант - WYSIWYG, и никаких претензий потом.

Чьей работы?

Английские буквы наводят сомнения.

Зато intertainment, "clever" house и проч. их развеивают

Да, там перлов полно, в том числе более серьезные.
Например, не к месту умное слово "Download"...

По взрослому это выглядит так:





В ucGUI очень по уму сделано обновление экрана, перерисовывается только то что изменилось.
Вывод битмапов даже может быть быстрее чем вы у себя реализовали, поскольку используют умный клипинг.
Вообще Micrium как базовую платформу для своего GUI предлагал 16-и разрядные процы M16 (24 МГц) в свое время.
Имел счастье портировать ucGUI на C167 (40 МГц).
Могу официально заявить на 320*240 там все летало.

Хотя если расскажете че делает ваш редактор меню, можно подумать о симбиозе ваших идей с ucGUI.

"Чем только не занимаются люди! Параллельно большому миру, в котором живут большие люди и большие вещи, существует маленький мир с маленькими людьми и маленькими вещами. В большом мире изобретен дизель-мотор, написаны "Мертвые души", построена Днепровская гидростанция и совершен перелет вокруг света. В маленьком мире изобретен кричащий пузырь "уйди-уйди", написана песенка "Кирпичики" и построены брюки фасона "полпред". В большом мире людьми двигает стремление облагодетельствовать человечество. Маленький мир далек от таких высоких материй. У его обитателей стремление одно - как-нибудь прожить, не испытывая чувства голода."
Ильф и Петров. Золотой Теленок.


320*240 - ключевые цифры. Упятерение размеров весьма критично.
Сейчас уезжаю в командировку, некогда.
На все нужно время, ну нету этой пары недель поиграться с GUI.

Не, ну заинтриговали и в кусты.
Хоть намекните. Ваш редактор генерирует хотспоты?
В ucGUI тоже такая фишка есть, он из найденных на экране рисунков кнопок автоматом генерирует хотспоты при фиксации нажатий на которые генерируется событие клавиатуры.

А почему бы вам для построения экранов не воспользоваться растровыми редактрами для WEB например Fireworks?
Он и рисунки создаст, и рассечет их на фрагменты и текстовый файл создаст с описанием где-че и какого размера должно стоять.
Вся работа, как говориться, в одном окне.

Есть уже аналогичная разработка у американцев, Amulet. Они внутрь операционную систему заложили, работает с HTML с небольшими ограничениями. http://www.amulettechnologies.com/
Используется для создания системы меню любой HTML редактор, ну и конечно чем дальше в лес, тем больше функций от HTML поддерживается.
Они пошли сразу в двух направлениях, продают свой дисплей и свой чип с встроенной ОС под HTML, который совместим с широкораспространенными
touchscreen и позволяет работать через редактор HTML.
Пробовал работать с Амулетом, по ощущениям не понравилось. На документах все красиво, но до красоты уровня игровой приставки очень далеко.
Думаю здесь история повторяется, только на еще более простом уровне. Самопальный редактор меню это по моему еще хуже, чем редактор HTML.
А вообще хочется такое решение, чтобы можно было создавать менюшки класса игровой приставки, вплоть до мультиков.
Тогда да, это будет супер решение.

Я не в кусты, я почти две тысячи проехал Поразительно, примерно одна и та же погода.


Генерация событий в зачатке. Размеры полей для тачскрина берутся конечно же из сгенерированного файла, но привязка действий ручками. Причина - действия заключаются в том числе в управлении другими устройствами по интерфейсу, не придумали как увязать. Идеи есть - использовать текстовый скрипт идентичный скрипту тестовой программы, но руки не дошли.


Одну из причин я упомянул - медленная ФС, а богатая графика тормозит ввод и/или распаковку.
Ну и нехватка ресурсов. Затыкаем дыры к выставке.

К вопросу о скорости LPC2xxx на LCD 320x240
http://slil.ru/26947484 (моя любимая игра когда-то)

Ролик декодируется (картинки PCX) в рилтайме. Если убрать задержки между кадрами, то будет 35 fps. И это на си. Если на асме, то 45-50 fps будет.

Подниму тему.
Во что вырасла технология распределенной визуализации у топикстартера?