ColorDialog - диалог выбора цвета

...
  • Преимущества по сравнению со включением в библиотеку Box_Lib - не распухает библиотека.
    Предлагаешь вместо того чтобы разбухать Box_Lib, плодить бинарники?
  • Общая либа для диалогов?
    Из хаоса в космос
  • Да, это удобно.
  • s1n wrote:
    Преимущества по сравнению со включением в библиотеку Box_Lib - не распухает библиотека.
    Предлагаешь вместо того чтобы разбухать Box_Lib, плодить бинарники?
    Есть отдельное окно в котором выбирается цвет и его подключение к программе для программиста содержит минимальные расходы - как по размеру кода, так и по организационной структуре. Я думаю это наиболее годный вариант и наличие еще одного бинарника это меньшее из зол. Как пример OpenDialog, подключение которого достаточно просто.
    Хочу заметить, что код и данные библиотеки обычно висят в памяти весь сеанс работы приложения, от его запуска до его завершения. OpenDialog не занимает память все время - только когда пользователь его запросил и работает с ним.
    Leency wrote: Общая либа для диалогов?
    Нет, не библиотека. Это будет работать также как OpenDialog, через именованную (расшаренную) память.
  • Хорошо, а в какую папку его тогда? В сыс? А опендиал в фм. А ещё что-то в девелоп? И т.д. Мне вот это интересно. Может общую папку какую-то?
    Из хаоса в космос
  • Mario wrote: ...наличие еще одного бинарника это меньшее из зол...
    [без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]
  • s1n wrote:
    Mario wrote:...наличие еще одного бинарника это меньшее из зол...
    [без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]
    Сейчас - да. А потом? Такой диалог нужен в текстовом и табличном процессорах, редакторах графики, для программы desktop не помешал бы, по-хорошему и веб-браузере нужен. Это лишь то, что пришло на ум. Открывать/сохранять файлы тоже не везде нужно, к примеру.
  • Leency wrote: Хорошо, а в какую папку его тогда? В сыс? А опендиал в фм. А ещё что-то в девелоп? И т.д. Мне вот это интересно. Может общую папку какую-то?
    Для меня это не принципиально.
    s1n wrote:
    Mario wrote:...наличие еще одного бинарника это меньшее из зол...
    [без_обид_и_наездов]Насколько это хорошо? OpenDialog используется в чуть более, чем почти всех программах. Тогда ОК. ColorDialog используется чуть, более в 2,5 программах. Это получается по сути UNIX-вэй.[/без_обид_и_наездов]
    Я не делю реализацию на Виндовс, Юникс или еще какой путь. Для меня важна эффективность. Реализация тем же путем, что использован для реализации OpenDialog - в данном конкретном случае более эффективно, чем располагать такую функциональность в библиотеке.
    А насчет 2,5 программ - давай посчитаем поточней где используется выбор цвета в уже существующих программах Колибри: PIC4, Animage, Desktop, zSea - итого уже 4 программы. OpenDialog, когда я только его начал внедрять, тоже использовался немногими программами и если бы я и IgorA не приложили усилия по внедрению, то ничего бы и не было.
  • Может поможет http://habrahabr.ru/blogs/ui/92781/
  • Процесс идет.
    Spoiler:cs_kolibri_1.png
    К слову весь код который вывел окошко, создал области с палитрой и оттенком, и вывел их в окно - без сжатия 858 байт.

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

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

    Запуск в Qemu, частота виртуальной машины приведена на скриншоте. Все замеры в сотых долях секунды, так как точнее не позволяет функция 26.9
    Первое число вычисление тоновой области (квадратная такая), второе вычисление области палитры (прямоугольная полоска), третье число - общее время с рисованием окна приложения..
    Spoiler:test_cs_asm.png
    Вот исходный код ассемблерного приложения:
    Spoiler:color_select.7z
    Естественно замеренное время не стабильно, так как это эмулятор. Еще прошу заметить, что я даже align 4 в начале каждой процедуры не расставлял, кстати надо будет попробовать.
    Естественно наличие измерительного когда немного увеличило размер приложения, в данный момент 1033 байт, еще добавило немного вынесение деления за пределы цикла (где это было возможно).
  • Who is online

    Users browsing this forum: No registered users and 3 guests