Board.KolibriOS.org

Official KolibriOS board
It is currently Mon Jul 22, 2019 7:23 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 76 posts ]  Go to page 1 2 3 4 5 6 Next
Author Message
PostPosted: Fri Sep 30, 2011 6:49 pm 
Мне тут потребовалось реализовать выбор цвета пользователем для программы zSea и я уже начал над ним работу.
Первоначально хотел внедрить в Box_Lib, но в процессе обратил внимание, что в Виндовс используется единообразный диалог для большинства программ, которые взаимодействую с пользователем на предмет выбора цвета и оформлен он в виде отдельного окна:
Spoiler: Show
cs_win.png

Естественно он не у всех такой. Например, в Gimp он такой:
Spoiler: Show
cs_gimp.png

Если честно, то Gimp мне кажется более удобным, вопрос вкуса естественно.
Я решил реализовать подобие последнего, вернее его левую часть и пока сделал только это:
Spoiler: Show
cs_kolibri.png

Изображение нарисовано кодом (ассемблерным хочу заметить) и свободно растягивается и сжимается при указании нужных координат.
Основная мысль сделать также как я реализовал OpenDialog, а именно - отдельной программой и вызовом через Proc_Lib
Преимущества по сравнению со включением в библиотеку Box_Lib - не распухает библиотека. Хотя сами процедуры выведения цветных диаграммм можно разместить в какую-нибудь библиотеку, но пока не вижу им другого применения как для ColorDialog

Если у кого есть конструктивные предложения или дополнения - излагайте. Может в Linux есть такие универсальные компоненты для сравнения? У меня просто времени не было заниматься целенаправленным поиском.


Top
   
PostPosted: Fri Sep 30, 2011 6:54 pm 
Offline
User avatar

Joined: Tue Jan 24, 2006 8:50 am
Posts: 249
Quote:
Преимущества по сравнению со включением в библиотеку Box_Lib - не распухает библиотека.

Предлагаешь вместо того чтобы разбухать Box_Lib, плодить бинарники?


Top
   
PostPosted: Fri Sep 30, 2011 6:59 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5053
Общая либа для диалогов?

_________________
Через тернии к звездам


Top
   
PostPosted: Fri Sep 30, 2011 7:07 pm 
Offline
User avatar

Joined: Tue Aug 25, 2009 4:45 pm
Posts: 794
Да, это удобно.


Top
   
PostPosted: Fri Sep 30, 2011 7:10 pm 
s1n wrote:
Quote:
Преимущества по сравнению со включением в библиотеку Box_Lib - не распухает библиотека.

Предлагаешь вместо того чтобы разбухать Box_Lib, плодить бинарники?

Есть отдельное окно в котором выбирается цвет и его подключение к программе для программиста содержит минимальные расходы - как по размеру кода, так и по организационной структуре. Я думаю это наиболее годный вариант и наличие еще одного бинарника это меньшее из зол. Как пример OpenDialog, подключение которого достаточно просто.
Хочу заметить, что код и данные библиотеки обычно висят в памяти весь сеанс работы приложения, от его запуска до его завершения. OpenDialog не занимает память все время - только когда пользователь его запросил и работает с ним.
Leency wrote:
Общая либа для диалогов?

Нет, не библиотека. Это будет работать также как OpenDialog, через именованную (расшаренную) память.


Top
   
PostPosted: Fri Sep 30, 2011 7:20 pm 
Offline
Designer
User avatar

Joined: Thu Jan 25, 2007 3:33 pm
Posts: 5053
Хорошо, а в какую папку его тогда? В сыс? А опендиал в фм. А ещё что-то в девелоп? И т.д. Мне вот это интересно. Может общую папку какую-то?

_________________
Через тернии к звездам


Top
   
PostPosted: Fri Sep 30, 2011 7:44 pm 
Offline
User avatar

Joined: Tue Jan 24, 2006 8:50 am
Posts: 249
Mario wrote:
...наличие еще одного бинарника это меньшее из зол...

[без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]


Top
   
PostPosted: Fri Sep 30, 2011 8:22 pm 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
s1n wrote:
Mario wrote:
...наличие еще одного бинарника это меньшее из зол...

[без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]

Сейчас - да. А потом? Такой диалог нужен в текстовом и табличном процессорах, редакторах графики, для программы desktop не помешал бы, по-хорошему и веб-браузере нужен. Это лишь то, что пришло на ум. Открывать/сохранять файлы тоже не везде нужно, к примеру.


Top
   
PostPosted: Fri Sep 30, 2011 8:30 pm 
Leency wrote:
Хорошо, а в какую папку его тогда? В сыс? А опендиал в фм. А ещё что-то в девелоп? И т.д. Мне вот это интересно. Может общую папку какую-то?

Для меня это не принципиально.
s1n wrote:
Mario wrote:
...наличие еще одного бинарника это меньшее из зол...

[без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]

Я не делю реализацию на Виндовс, Юникс или еще какой путь. Для меня важна эффективность. Реализация тем же путем, что использован для реализации OpenDialog - в данном конкретном случае более эффективно, чем располагать такую функциональность в библиотеке.
А насчет 2,5 программ - давай посчитаем поточней где используется выбор цвета в уже существующих программах Колибри: PIC4, Animage, Desktop, zSea - итого уже 4 программы. OpenDialog, когда я только его начал внедрять, тоже использовался немногими программами и если бы я и IgorA не приложили усилия по внедрению, то ничего бы и не было.


Top
   
PostPosted: Sat Oct 01, 2011 9:46 pm 
Offline
User avatar

Joined: Sun May 10, 2009 7:56 pm
Posts: 98
Может поможет http://habrahabr.ru/blogs/ui/92781/


Top
   
PostPosted: Sat Oct 01, 2011 11:12 pm 
Процесс идет.
Spoiler: Show
cs_kolibri_1.png

К слову весь код который вывел окошко, создал области с палитрой и оттенком, и вывел их в окно - без сжатия 858 байт.

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


Top
   
PostPosted: Sun Oct 02, 2011 8:56 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
Не знаю твоего алгоритма, я реализовал похожий градиент (тот, что справа) через три вложенных цикла и скомпилировал его для linux. Вывод делал в консоль через printf.
Линкованный динамически занимает 5504 байта, линкованный статически - 552 килобайта.
Если компилировать тот же код для kolibri с помощью menuetlibc, получается файл около 1 килобайта.
Изменение высоты полосы не предусмотрено.

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


Top
   
PostPosted: Sun Oct 02, 2011 9:38 am 
Offline
Just Flooding

Joined: Sat Jan 06, 2007 2:30 pm
Posts: 269
Троллинг действительно толстый. Ибо надо определяться: вам шашечки или ехать. Компиляторы оптимизируют по скорости выполнения, а не по размеру. По размеру ни gcc, ни msvc (не надо тыкать мне в опцию -Os) не умеют оптимизировать, да и считается что никому не нужно. В общем-то, я только в c-- видел фичу, что можно задавать: что оптимизировать по размеру, а что по скорости. А фича очень вкусная, ибо большую часть кода по скорости оптимизировать совсем не надо и современные ОС могли бы занимать куда меньше места.


Top
   
PostPosted: Sun Oct 02, 2011 11:30 am 
Offline

Joined: Mon Sep 24, 2007 11:11 am
Posts: 2814
А вот я и предлагаю сделать бенчмарк.


Top
   
PostPosted: Sun Oct 02, 2011 3:40 pm 
Что же попробую троллить потоньше. :mrgreen:

Запуск в Qemu, частота виртуальной машины приведена на скриншоте. Все замеры в сотых долях секунды, так как точнее не позволяет функция 26.9
Первое число вычисление тоновой области (квадратная такая), второе вычисление области палитры (прямоугольная полоска), третье число - общее время с рисованием окна приложения..
Spoiler: Show
test_cs_asm.png

Вот исходный код ассемблерного приложения:
Spoiler: Show
color_select.7z

Естественно замеренное время не стабильно, так как это эмулятор. Еще прошу заметить, что я даже align 4 в начале каждой процедуры не расставлял, кстати надо будет попробовать.
Естественно наличие измерительного когда немного увеличило размер приложения, в данный момент 1033 байт, еще добавило немного вынесение деления за пределы цикла (где это было возможно).


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 76 posts ]  Go to page 1 2 3 4 5 6 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited