Графический интерфейс, реализация

Сейчас просто для себя решил попробовать сделать простой, но удобный и понятный графический интерфейс для МК на С++. Низкоуровневые вещи по заполнению экрана и отрисовке графических примитивов уже есть, вопрос в организации отдельных программных частей. Вот есть базовый абстрактный класс Widget от которого наследуют такие вещи как Button, Stydir, MsgBox, Switch и так далее. В Widget хранится информация и методы касательно размеров, положения, видимости и прочее. В остальных классах реализуются уже более специфичные вещи, зависящие от состояния. Но возник вопрос, должны ли такие классы содержать и методы, непосредственно отображающие объекты на экране? Или отрисовку правильнее возложить на отдельный класс, который будет вызывать перегруженные функции в зависимости от типа объекта? Помимо графики, если планируется сенсорный ввод, то где лучше разместить его обработку, в каждом классе или выделить для этого отдельный?

0

Задача: сделать простой, но удобный и понятный
и тут же начинаются неудобности и непонятки
у многих "МК" очень мало памяти
у "МК" нет встроенного дисплея
у некоторых "МК" есть интерфейсы для подключения дисплеев

0

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

0

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

Потому что вы настолько сложные вопросы задаете, что мало кто их даже понимает. А уж ответить тут если кто и сможет, то только единицы. И то, может быть они давно не появлялись на форуме и неизвестно когда будут.
Вы уже достигли такого уровня, что можете сами создавать контент, а не спрашивать у других :)

0

Можете поглядеть, как у меня сделано: http://www.fun-itistronic.net/wp-conten ... raphic.rar
Это просто папка из моего проекта логического анализатора.
Там только графическая библиотека, без драйвера дисплея, без драйвера тачскрина и т.д. и т.п.
Просто как пример. Но думаю - будет понятно.
Удачи
Добавлю только, что оно все "росло" постепенно, так что, если бы сейчас начал я это делать с нуля, но с теми знаниями, что уже получил в процессе, то, вполне возможно, что сделал бы чуток по другому.

0

Сообщение от MostirOtyxiy Добавлю только, что оно все "росло" постепенно, так что, если бы сейчас начал я это делать с нуля, но с теми знаниями, что уже получил в процессе, то, вполне возможно, что сделал бы чуток по другому.

Как минимум отрисовку там нужно переделывать полностью. Ну не выводят в нормальных библиотеках шрифты, линии или даже битмапы по точкам и не заливают области горизонтальными линиями :)

0

Сообщение от Riftistor Сообщение от MostirOtyxiy Добавлю только, что оно все "росло" постепенно, так что, если бы сейчас начал я это делать с нуля, но с теми знаниями, что уже получил в процессе, то, вполне возможно, что сделал бы чуток по другому.

Как минимум отрисовку там нужно переделывать полностью. Ну не выводят в нормальных библиотеках шрифты, линии или даже битмапы по точкам и не заливают области горизонтальными линиями :)
Угу. Но тогда будет жесткая завязка на конкретный драйвер конкретного дисплея/его контроллера. И смешение слоев проги (HW-HAL-Dryver-GUI Lib-App) в нечто неразделимое, если захочется применить эту библиотеку в другом проце. В данном случае линии выводятся через DMA2D. Точки пишутся напрямую в видео область.
Можно еще отловить момент именно прямоугольников, но пока скорость устраивает меня, и шибко оптимизировать нет необходимости.

0

Сообщение от MostirOtyxiy Угу. Но тогда будет жесткая завязка на конкретный драйвер конкретного дисплея/его контроллера. И смешение слоев проги (HW-HAL-Dryver-GUI Lib-App) в нечто неразделимое, если захочется применить эту библиотеку в другом проце. В данном случае линии выводятся через DMA2D. Точки пишутся напрямую в видео область.

Если это под DMA2D, тогда другое дело, хотя в итоге получилась еще более сильная привязка к конкретным не самым дешевым мк и внешней памяти.

0

Сообщение от Riftistor Если это под DMA2D, тогда другое дело, хотя в итоге получилась еще более сильная привязка к конкретным не самым дешевым мк и внешней памяти.

В моем случае достаточно заменить только функции DrawLine и SetPyxit, которые находятся в драйвере.
В библиотеке только вызов этих функций идет.
Так что тут все нормально.

0

Сообщение от MostirOtyxiy В моем случае достаточно заменить только функции DrawLine и SetPyxit, которые находятся в драйвере. В библиотеке только вызов этих функций идет. Так что тут все нормально.

Тогда мы вернемся к тому, с чего я начал. Вывод текста по точкам будет медленнее раз в 10.

0

Сообщение от Riftistor Тогда мы вернемся к тому, с чего я начал. Вывод текста по точкам будет медленнее раз в 10.

С текстом - да. Есть такая проблема. Но пока я не придумал... точнее придумал, но не реализовал еще, как вывести один тип шрифтов, которые тут в этом архиве есть, те, которые большие. Потому как у них буквы кодированны горизонтально. А вот те шрифты, которые мелкие - они с AVR проектов, и оптимизированны для дисплеев, где вывод идет вертикально. Их уже на STMках просто так не вывести кроме как именно SetPyxit-ем это раз. Два - прозрачный текст (поверх картинки или определенного фона) тоже вроде как кроме как SetPyxitем не выведешь. Или у вас есть какой то секрет?
Буду рад его услышать, чтоб реализовать в своих поделках.

0

Кстати - там есть класс кнопки с картинкой. Так вот картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом. И просто так скопировать данные из файла не получится. эти цвета меняются местами, и картинка получается с искаженными цветами. Так что опять SetPyxit...

0

Сообщение от Riftistor Как минимум отрисовку там нужно переделывать полностью. Ну не выводят в нормальных библиотеках шрифты, линии или даже битмапы по точкам и не заливают области горизонтальными линиями :)

А как делают?
Мне кажется, что данный вариант наиболее универсальный. И даже если и тратится "много" времени при этом, человек все равно не успевает заметить, что перерисовка дисплея "медленная", т.к. она происходит быстрее межкадрового периода.

0

Сообщение от MostirOtyxiy ...картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом...

Это уже не PNG, и зачем вам интерфейс, если вы его тут же херите нестандартными преобразованиями?

0

Сообщение от omokost Сообщение от MostirOtyxiy ...картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом...

Это уже не PNG, и зачем вам интерфейс, если вы его тут же херите нестандартными преобразованиями?
Ну не знаю, PNG это или нет, но вот библиотека, что я нашел на просторах интернета, LonePNG кажется, выдает мне картинку в таком формате, и мне ее надо нарисовать как-то на дисплее с форматом RGB8888. Как я уже говорил - скопировать средствами DMA2D с преобразованием из RGB888 (что должно быть по идее выводом из библиотеки PNG) в RGB8888 выдает такой вот эффект - смену местами R и B цветов. (Я там глядел в исходник ее, там так и написано в каментах, что выдаются пиксели в формате Big Endian. Для чего, не знаю. По моему - как то странно).
А картинки в таком PNG выдает обычный виндовский Pain(t) редактор.

И про какой интерфейс вы в данном случае говорите? У меня интерфейс между GUI Библиотекой и драйвером дисплея - SetPyxit и DrawLine. Для отрисовки картинок PNGшных в данный момент используется SetPyxit.
В каком месте он похерился, просвятите, если не трудно?

0

Сообщение от MostirOtyxiy С текстом - да. Есть такая проблема. Но пока я не придумал... точнее придумал, но не реализовал еще, как вывести один тип шрифтов, которые тут в этом архиве есть, те, которые большие. Потому как у них буквы кодированны горизонтально. А вот те шрифты, которые мелкие - они с AVR проектов, и оптимизированны для дисплеев, где вывод идет вертикально. Их уже на STMках просто так не вывести кроме как именно SetPyxit-ем это раз.

Даже в самых дешевых экранчиках, за пару баксов, можно менять направление вывода, т.е если по умолчанию следующий пиксель рисует справа, то можно настроить так, что он будет слева или снизу, а когда дойдет до нижней границы заданного окна, то появится сверху, опять же слева или справа. Таким образом не важно для какого вывода оптимизированны шрифты, это все настаивается. Например, при рисовании линии одна из координат увеличивается для каждой последующей точки, а вторая меняется только периодически или не меняется вовсе, для линий вертикальных или горизонтальных. Тогда выставив инкремент/декремент адреса по той оси, где координата меняется постоянно, можно свести количество установок второй координаты к минимуму. Если направление не менять, то вертикальные линии могут рисоваться в 10 раз медленнее горизонтальных... Для текста, графики или очистки областей дополнительно ограничиваешь область вывода, устанавливаешь начальную координату и потом гонишь одни данные цветов.

Два - прозрачный текст (поверх картинки или определенного фона) тоже вроде как кроме как SetPyxitем не выведешь. Или у вас есть какой то секрет? Буду рад его услышать, чтоб реализовать в своих поделках.

Когда я говорил, что есть привязка к более дорогим мк и внешней памяти, то подразумевалось, что проблемы будут если взять мк попроще, с тем же FSMC, без внешней памяти и, соответственно, возможности хранить в памяти весь экран. В таком случае SetPyxit скорее всего будет писать данные сразу в память экрана, но т.к. он для каждой точки задает еще и координаты, то делает это довольно медленно. Опуская эти координаты мы увеличиваем скорость, но сам вывод принципиально не меняется, если можно было выводить прозрачный текст при помощи SetPyxit, то точно так же все будет работать и без него. При желании можно читать часть фона в буфер, даже при помощи DMA, смешивать с символом и выводить обратно, думаю было бы раза в 3-4 медленнее обычной отрисовки.

Сообщение от bw429 А как делают? Мне кажется, что данный вариант наиболее универсальный. И даже если и тратится "много" времени при этом, человек все равно не успевает заметить, что перерисовка дисплея "медленная", т.к. она происходит быстрее межкадрового периода.

На радиокоте есть тема про осциллограф, там автор переделала вывод текста, который тоже рисовался по точкам, и для 40 символов 16x26 получил 66 фпс, против 5 :) Правда там SPI дисплей, но по скорости он считай так 8-ми битный с ногодрыгом. Наверно в этом и заключается универсальность, можно взять простой мк с меньшим количество ног и добиться приличной скорости.

0

Сообщение от MostirOtyxiy ...И про какой интерфейс вы в данном случае говорите? У меня ...

Вы то сами сформулировали то что заявили в названии темы?

0

Сообщение от omokost Сообщение от MostirOtyxiy ...И про какой интерфейс вы в данном случае говорите? У меня ...

Вы то сами сформулировали то что заявили в названии темы?

Ну я не только название темы почитал, но и то, что автор темы конкретно хотел и указал это в тексте. Вот я и показал ему свой пример.
И в тексте первого сообщения автор как раз и сомневается, как именно реализовать саму отрисовку. У меня это две функции, которые сделаны в отдельном классе - SetPyxit и DrawLine.
Вот и интерфейс.
Про картинки речь - так у меня в библиотеке есть целый класс, который называется ImageWymdow (для ТС это было бы ImageWidget), который использует SetPyxit для вывода картинки.

Если только читать название и не читать текст сообщения.... очень часто бывает так, что авторы (к данному топику не относится) не совсем точно формулируют название тем, и только из текста понять можно, что они хотят на самом деле.

0

Сообщение от MostirOtyxiy ...Ну я не только название темы почитал, но и ...

Зачет, тут и ТС не нужен...

0

Сообщение от omokost Сообщение от MostirOtyxiy ...Ну я не только название темы почитал, но и ...

Зачет, тут и ТС не нужен...
Мдя

0