Easyelectronics.ru

Электроника для всех
Текущее время: 23 июл 2018, 03:00

Часовой пояс: UTC + 5 часов



    • JLCPCB - Платы прототипов всего за 2$ c бесплатной доставкой (при первом заказе)
    • 10 PCBs за $2 для 2 слоев, $15 для 4 слойной, $74 для 6 слойной платы.
    • Крупнейший китайский производитель прототипных плат. 290000+ клиентов & 8000+ заказов в день!
    • LCSC - Крупнейший китайский онлайн магазин радиодеталей.

Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Графический интерфейс, реализация
СообщениеДобавлено: 15 апр 2017, 02:40 
Старожил

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 15 апр 2017, 11:42 
Старожил

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 00:15 
Старожил

Зарегистрирован: 19 фев 2015, 17:37
Сообщения: 1159
Откуда: void
Ну я же написал, что низкоуровневые вещи пока оставляю за скобками, меня больше интересует сам принцип организации отдельных программных модулей в составе библиотеки графического интерфейса.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 00:30 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
Faberge писал(а):
Ну я же написал, что низкоуровневые вещи пока оставляю за скобками, меня больше интересует сам принцип организации отдельных программных модулей в составе библиотеки графического интерфейса.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 00:59 
Старожил
Аватара пользователя

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 13:01 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 564
MasterAlexei писал(а):
Добавлю только, что оно все "росло" постепенно, так что, если бы сейчас начал я это делать с нуля, но с теми знаниями, что уже получил в процессе, то, вполне возможно, что сделал бы чуток по другому.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 14:26 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Reflector писал(а):
MasterAlexei писал(а):
Добавлю только, что оно все "росло" постепенно, так что, если бы сейчас начал я это делать с нуля, но с теми знаниями, что уже получил в процессе, то, вполне возможно, что сделал бы чуток по другому.

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

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 14:52 
Старожил

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 15:18 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Reflector писал(а):
Если это под DMA2D, тогда другое дело, хотя в итоге получилась еще более сильная привязка к конкретным не самым дешевым мк и внешней памяти.

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 15:22 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 564
MasterAlexei писал(а):
В моем случае достаточно заменить только функции DrawLine и SetPixel, которые находятся в драйвере.
В библиотеке только вызов этих функций идет.
Так что тут все нормально.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 15:36 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Reflector писал(а):
Тогда мы вернемся к тому, с чего я начал. Вывод текста по точкам будет медленнее раз в 10.

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 15:38 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Кстати - там есть класс кнопки с картинкой. Так вот картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом. И просто так скопировать данные из файла не получится. эти цвета меняются местами, и картинка получается с искаженными цветами. Так что опять SetPixel...

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 15:55 
Старожил

Зарегистрирован: 18 июл 2016, 21:17
Сообщения: 746
Reflector писал(а):
Как минимум отрисовку там нужно переделывать полностью. Ну не выводят в нормальных библиотеках шрифты, линии или даже битмапы по точкам и не заливают области горизонтальными линиями :)

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 17:42 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2011, 11:24
Сообщения: 3694
Откуда: г. Липецк
MasterAlexei писал(а):
...картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 18:12 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
anakost писал(а):
MasterAlexei писал(а):
...картинки у меня в основном в PNG формате. И в нем - этом PNG формате байты цвета R и B местами поненяны по сравнению с нормальным форматом...

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

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

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 18:24 
Старожил

Зарегистрирован: 23 янв 2016, 15:37
Сообщения: 564
MasterAlexei писал(а):
С текстом - да. Есть такая проблема. Но пока я не придумал... точнее придумал, но не реализовал еще, как вывести один тип шрифтов, которые тут в этом архиве есть, те, которые большие. Потому как у них буквы кодированны горизонтально. А вот те шрифты, которые мелкие - они с AVR проектов, и оптимизированны для дисплеев, где вывод идет вертикально. Их уже на STMках просто так не вывести кроме как именно SetPixel-ем это раз.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 18:34 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2011, 11:24
Сообщения: 3694
Откуда: г. Липецк
MasterAlexei писал(а):
...И про какой интерфейс вы в данном случае говорите? У меня ...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 18:42 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
anakost писал(а):
MasterAlexei писал(а):
...И про какой интерфейс вы в данном случае говорите? У меня ...

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


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

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

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 19:08 
Старожил
Аватара пользователя

Зарегистрирован: 28 дек 2011, 11:24
Сообщения: 3694
Откуда: г. Липецк
MasterAlexei писал(а):
...Ну я не только название темы почитал, но и ...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 16 апр 2017, 19:11 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
anakost писал(а):
MasterAlexei писал(а):
...Ну я не только название темы почитал, но и ...

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

Мдя

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 19 апр 2017, 15:04 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 750
Каждый потомок Widget должен содержать перегружать виртуальную функцию, занимающуюся его отрисовкой. В библиотеки qt такая функция называется paintEvent. Это очень логично спросить у виджета, как его следует отрисовать. Конечно, этот метод можно реализовать и в виде внешней перегруженной функции, но смысла в этом нет. При этом данному методу не следует знать абсолютных координат, а работать с координатами виджета.

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

Вообще, общая рекомендация моя такая. Есть замечательная библиотека Qt, откуда идеи можно черпать и черпать. Есть книга по Qt за авторством господина Шлее. Она, конечно, написана с точки зрения пользователя, а не программиста, но там все весьма прозрачно, если внимательно следить, откуда берется кролик. Просто посмотрите, как ваши вопросы реализованы в Qt по части интерфейса, максимально упростите и получите профит.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 19 апр 2017, 15:11 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 750
Господа. Ну вы как всегда. Вопросы заданы конкретные, ответы - кто во что горазд... Ну сами понимаете...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 19 апр 2017, 15:34 
Старожил
Аватара пользователя

Зарегистрирован: 29 янв 2010, 15:41
Сообщения: 1125
Откуда: Германия
Mirmik писал(а):
Каждый потомок Widget должен содержать перегружать виртуальную функцию...
и получите профит.

Ну и чем описанное вами отличается от того, что у меня в моем куске моей библиотеки?
Так оно и реализовано по алгоритмике. Может чуток по другому по стилю программирования, но алгоритмы те же.
Так что я считаю, что на поставленный вопрос я ответил.

_________________
Мои поделки
http://www.fun-electronic.net/


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 19 апр 2017, 17:52 
Старожил
Аватара пользователя

Зарегистрирован: 24 июл 2012, 13:54
Сообщения: 750
Ваш ответ по теме. Глобально против вашего ответа я ничего не имею.

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

Но, это так... Мысли на тему.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Графический интерфейс, реализация
СообщениеДобавлено: 19 апр 2017, 18:03 
Заглядывает иногда

Зарегистрирован: 30 июн 2015, 14:16
Сообщения: 50
Faberge,
Подходов куча. Сейчас похожей задачей занимаюсь. Решил сделать 2 интерфейсных класса:
1. Для управления графическими объектами, строками и т.д.
2. Для управления драйвером экрана
Для тача отдельный класс. Фрейм-буффер в виде списка с объектами + тач. Вывод на экран - итерация списка.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 35 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 5 часов


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB