Page 4 of 7
Posted: Thu Jan 11, 2007 7:19 pm
by diamond
Рекомендую сверить giflib.inc с gif_lite.inc из дистрибутива K0600 или 0630. А то у меня есть вредная привычка исправлять глюки и никому об этом не говорить.
Posted: Mon Jan 22, 2007 5:32 pm
by andrew_programmer
Victor
Это один из глюков примитивного меню.Как я уже говорил,меню делалось для временного использования.Нужно писать нормальное полноценное меню(в общем библиотеку универсального и полноценного GUI).Как автор программы я знаю обовсех багах в ANIMAGE(в том числе и о тех,которые вы ещё не заметили
).
Mario79
Для того,чтобы KFM запускал ANIMAGE для редактирования BMP файлов, необходимо в KFM.INI файле написать строку:
bmp /rd/1/animage
Марат, сделать в KFM возможность выбора между MV и ANIMAGE - это уже к тебе.
diamond
Хорошо,проверю.
P.S.
На этих каникулах я хотел заниматься разработкой ANIMAGE, но по независящим от меня причинам(тяжёлые жизненные обстоятельства в семье) я не смогу этого сделать.
Posted: Mon Jan 22, 2007 5:43 pm
by Serge
andrew_programmer
Похоже что при выходе через меню редактор не удаляет курсоры.
Posted: Mon Jan 22, 2007 5:54 pm
by andrew_programmer
Проверю.
Я уже немного подзабыл код ANIMAGE.
Posted: Mon Jul 30, 2007 1:20 am
by Leency
andrew_programmer
Извиняюсь за назойливость)), но мож у тебя появилось время доделать полосы прокрутки? Сейчас они большие, т.к. таскать можно только за них. Но в некоторых прогах (KFM например) уже реализован код когда можно сводить курсор с полос прокрутки.
Мм.. ещё. Если закрыть диалог "Открыть" или "Сохранить как...", то меню стаёт неактивным и рисовать уже нельзя.
В любом случае удачи.
Posted: Mon Jul 30, 2007 1:36 am
by andrew_programmer
Дела я всегда делаю в порядке степени приоритетности.
Leency, поверь, как только приоритет дойдёт до графического редактора - займусь им.
С появлением библиотеки libGUI набросать на форму скролер стало делом пяти минут. Вот только код ANIMAGE писался до появления libGUI, поэтому нужно значительно переделывать код ANIMAGE под libGUI. К тому-же надо переделывать работу с памятью под новый менеджер памяти Колибри.
А меню - тема для отдельного разговора. Надо несколько переделать оконную систему Колибри для его реализации.
Posted: Mon Jul 30, 2007 2:43 am
by bw
А что с памятью kos, можно ссылку на акцент данного вопроса?
..bw
Posted: Mon Jul 30, 2007 11:46 am
by diamond
bw
В MenuetOS и ранних версиях Колибри единственной возможностью работы с динамической памятью было изменение размера памяти функцией 64. После трудов Serge появилось действительно выделение/освобождение блоков памяти 68.11/12/13, но ещё не все программы об этом знают.
Posted: Mon Jul 30, 2007 9:08 pm
by Mario79
andrew_programmer
Давно заметил такое дело (но все забывал написать): в Qemy 64 Мб памяти прописано, BMP файл размером 10 Мб не открывается – черный фон вместо файла, прописываю 128 Мб, все открывается. На реальном компере (старый Cyrix) памяти 32 Мб – файлы больше 1,5 Мб (приблизительно) тоже не открываются.
Вот у меня и возник вопрос – глюк программы или как? Даже если считать что программа резервирует двойной размер памяти под файл и откаты, все равно должно открываться, так как системе требуется не более 7-8 Мб всего, это с учетом всех приложений, запущенных лаунчером при старте.
Posted: Tue Jul 31, 2007 12:26 pm
by andrew_programmer
Mario79
Размер расходуемой ANIMAGE памяти = 5MB+6*размер_распакованного_файла(3*размер_по_x*размер_по_y)
С появлением новых возможностей работы с файлами и нового менеджера памяти Колибри - можно уменьшить размер расходуемой памяти. Но полное переписывание ANIMAGE на новый менеджер памяти, новый интерфейс через libGUI, новую работу с файлами, займёт дней 7-10 непрерывной работы(с утра до вечера).
Мне этим летом нужно ещё некоторую работу выполнить, которая облегчит мне жизнь во время тяжёлой учёбы. Незнаю, останеться ли у меня этим летом время для ANIMAGE.
Posted: Tue Jul 31, 2007 12:48 pm
by Leency
andrew_programmer
Будим надеяться что удастцо, т.к. графический редактор - это очень важная составляющая операционной системы. Не дадим Менуетчикам (Вилле и ко) нас перегнать!
Posted: Tue Jul 31, 2007 1:12 pm
by Mario79
andrew_programmer
6*размер_распакованного_файла ?!!!!!!!! Шесть!!!!!!
Челюсть валяется где-то под столом у соседа....
Это зачем такие "скромные" потребности в памяти? Я чего-то не понимаю...
Posted: Tue Jul 31, 2007 3:15 pm
by andrew_programmer
Mario79
64 функция крайне скудна на возможности работы с памятью, поэтому приходиться резервировать буферы размером с распакованную картинку.Даже если нужно скопировать часть картинки размером 2х2 пиксела, под это всёравно выделяется буфер размером с распакованную картику.
А память в ANIMAGE распределяется так:
5MB -статический экранный буфер под максимальное разрешение 1280*1024
дальше идут буферы размером с распакованную картинку(назовём это pak)
1 pak для самой картинки
2 pak-а для двух отмен последнего действия
1 pak для хранения скопированной выделенной части картинки
1 pak для хранения фона под скопированной картинкой, чтобы при его перемещении по картинке он не затирал основное изображение.
1 pak При сохранениии картинки она сначала упаковывается в этот буфер, а потом только записывается в файл(раньше небыло 70-ой функции).
Сейчас, когда есть настоящее динамическое выделение памяти, ненужно выделять статические буферы. Нужно выделять динамические буферы в зависимости от действий пользователя при редактировании картинки. Это позволит варьировать размер расходуемой памяти от 3-х распакованных картинок(минимум) до 5(максимум)(в зависимости от действий пользователя).
Posted: Tue Jul 31, 2007 4:21 pm
by Mario79
andrew_programmer
Да нет, я в принципе ничего не имею против - просто удивил размер. В KFM я тоже использовал 64 функцию, а данные панелей в памяти таскаются туда сюда. Правда размер любой папки редко бывает больше размера BMP файла. Видимо мой подход оправдывается лишь при не очень больших объемах данных.
Posted: Fri Aug 24, 2007 4:00 pm
by Nable
1.Когда-то давно, когда я только учился програмировать, я писал на C++ под Винду, так вот в одной умной книжке я прочитал такую интересную вещь, что необязательно для отмены последних действий хранить всю картинку, альтернативный вариант - запоминать действия пользователя. В текстовом виде. Или в виде подобия опкодов. Когда буфер действий заполняется (а при таком виде заполнится он не скоро), то самое далёкое действие по дате выполняется над изображением, а остальные в буфере смещаются вниз. Действия, например, такие: MoveTo(x,y),LineTo(x,y),FloodFill(x,y)...
2.Я недавно на диске с учебниками математики обнаружил кучу литературы по обработке изображений(с примерами), с радостью, если есть время.