Board.KolibriOS.org

Nable
Спасибо за ссылки. Я думал что при сглажевании нужно расчитывать интенсивность цвета для заливки используя дробные числа, оказывается что можно выкрутится и через целые.
Asper
Алгоритм заливки выглядит очень простым, потому когда будет время то сперва добавлю в библиотеку функцию для заливки.

to Asper
Ты не прав, говоря что этот алгоритм не хранит координаты всех заливаемых точек. Ведь чем больше точек, тем больше глубина вложенности... Уже догадался что меняешь шило на мыло? Раньше было в массиве, теперь в стеке. Некоторая экономия есть, ибо хранится часть точек, а не все, а так же, с другой стороны, рекурсивный алгоритм, быть может, можно легко распаралеллить, но будь аккуратен, переполнение стека - опасная ошибка.

to IgorA
Числа на самом деле в итоге дробные, просто с фиксированной точкой, а не плавающей. Не знаю как сейчас, но раньше в ядре в коде сглаженного рисования фона использовалась fixed-point math 32.32

Nable
Именно в стеке и не нужно думать сколько памяти выделить под массив, как определить множество заливаемых точек и т.д. Про рекурсию и переполнение стека я конечно же знаю, и уж позабочусь о надлежащем размере стека, важнее то, что сама библиотека будет проще и быстрее заливать требуемую область.
Например вот здесь описываются несколько алгоритмов заливки. Приведенный мной алгоритм там обозначен как "Простой алгоритм заливки".

В ревизии 1684 добавил функцию buf2d_flood_fill, заливает области. Но смущает то, что чем больше заливаемая область тем больше должна быть область стека. Причем область нужная для стека растет намного быстрее чем я думал. При увеличении радиуса заливаемой области на 1 пиксель стек по идее должен увеличиваться на 4 байта (одна рекурсивная команда call = 4 байта). Так я думал, но на практике получаются большие цифры ...
Например круг радиусом 25 я могу залить со стеком 4096, а круг радиусом 50 пикселей я не могу залить со стеком 8192 зависимость не линейная

ну уж окружности то можно рисовать сразу линиями, а не точками, вот и заливка.. а для фигур произвольной формы то да, придется идти на определенные жертвы..

IgorA
S=2*pi*R*R
Для R=25, S=3297
Для R=50, S=15140

Наконец-то попробовал!
к сожалению, вынужден подтвердить. что демки рисуются криво, при этом демка ADOBE.SWf у меня вылетает с такой ошибкой:
Однако начинание хорошее и нужное, удачи!

Атауальпа wrote:при этом демка ADOBE.SWf у меня вылетает с такой ошибкой

Хочется узнать библиотека buf2d, которая была использована в тесте была до или после 1717 ревизии? Скорее всего ошибка не в этом, но вдруг... Алгоритм рисования закрашенного прямоугольника при задании отрицательных размеров мог или подвесить программу (ширина меньше 0) или привести к сбою программы (высота меньше 0), что было в 1717 устранено (хотя очень серйозных тестов по этому поводу я не проводил).

Да, библиотека оказалась действительно старая. А где новая, на svn я не нашёл.

Атауальпа wrote:А где новая, на svn я не нашёл

рядом с другими библиотеками в папке
programs/develop/libraries/buf2d
просмотреть в браузере можно по ссылке
http://redmine.kolibrios.org/projects/k ... /buf2d.asm

На сколько я знаю пока только одна программа использует эту функцию, потому заменить название не проблематично.
В английском я не силен
Со следующей ревизией поменяю.

Я примерно в пяти файлах по svn насчитал, один из которых html

Проще поиском по содержимому, в файловых менеджерах поискать. Например Krusader (для Linux) или Unreal Commander (соответственно для Windows).