Board.KolibriOS.org

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

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

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

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

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

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

Общая либа для диалогов?

_________________
Звиздеть не мешки ворочать

Да, это удобно.

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

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

Хорошо, а в какую папку его тогда? В сыс? А опендиал в фм. А ещё что-то в девелоп? И т.д. Мне вот это интересно. Может общую папку какую-то?

_________________
Звиздеть не мешки ворочать

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

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

Для меня это не принципиально.

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

Может поможет http://habrahabr.ru/blogs/ui/92781/

Процесс идет.

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

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

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

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

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

А вот я и предлагаю сделать бенчмарк.

Что же попробую троллить потоньше.

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

Вот исходный код ассемблерного приложения:

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