>Я как-то пытался написать алгоритм алиасинга для элипса без ресамплинга, чисто из геометрических соображений :)

Который алгоритм Wu уже давно реализован.

> Который алгоритм Wu уже давно реализован.
Спасибо, нашел, буду думать как его переделать для толщины линии >1

Без GDI+ можно. Смотри http://sourceforge.net/projects/graphics32

> homm ©   (12.03.07 08:47) [17]
> > [15] antonn ©   (12.03.07 00:22)
>
> Судя по скриншоту там ресамплинг по квадрату 3х3. Я как-
> то пытался написать алгоритм алиасинга для элипса без ресамплинга,
>  чисто из геометрических соображений :) По моему это должно
> быть более эффективно, но увы, так ничего и не получилось.
>

По поводу антиалиазинга хотел посоветоваться, раз уж пост всплыл. Каков бы не был алгоритм рисования того же эллипса с антиалиазингом есть проблема вот какого рода.

Допустим нам надо сделать функцию, аналогичную функции GDI но с анталиазингом: Ellipse(DC, x1, y1, x2, y2). Как бы мы не рисовали точки, нам один фиг не пройти либо Set/GetPixel, что довольно медленно, либо надо созавать временный битмап, копировать на него точки, пробегать сканлайном по нему менять цвета точке в соответствии с алгоритмом рисования и далее битмап выводить обратно на DC. При маленьких размерах эллипса это быстрее, чем SetPixel, но при больших даже медленнее.
Вот если бы как то можно было бы добраться до отдельных пикселей DC напрямую. Как вообще работают стандартные функции рисования Windows. Они явно не пользуются для изменения цвета точки функциями SetPixel.
Нет ли каких идей?

имхо только set/getpixels для канвы...
вот поэтому я предпочитаю все рисовать на буферном битмапе, битмап он более "физический", чем указатель-hdc, по нему можно циклом на асме пройтись и добраться до пикселей даже быстрее сканлайна.

> вот поэтому я предпочитаю все рисовать на буферном битмапе,
>  битмап он более "физический", чем указатель-hdc, по нему
> можно циклом на асме пройтись и добраться до пикселей даже
> быстрее сканлайна.

Сканлайном я лишь метод обозначил. На асме или нет, но при больших размерах этот метод медленнее, чем то же самое, но через SetPixel.

> [24] DVM ©   (22.01.08 15:19)
> При маленьких размерах эллипса это быстрее, чем SetPixel,
> но при больших даже медленнее.

Напрасно ты так думаешь. Размер тут не причем.

> Напрасно ты так думаешь.

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

Пример: окружность радиус 100
через SetPixel - 16800 микросекунд
через Scanline - 3400 микросекнд

Пример: окружность радиус 500
через SetPixel - 35000 микросекунд
через Scanline - 20000 микросекнд

Пример: окружность радиус 700
через SetPixel - 32000 микросекунд
через Scanline - 29000 микросекнд

Для роадиуса 1000 сканлайн уже отстает

Функции GDI уже давно во всю используют аппаратное ускорение. Проблема с DC даже не в том, что он менее «физический», просто объект, для работы с которым DC является идентификатаром, находится в виделпамяти (при наличии доступной оной).

Но при расчете эллипса вывод это дело 10-е, важнее математика. У меня есть алгоритм идеально сглаженного заполненного эллипса. У меня есть алгоритм получения (что проще) идеальной окружности с произвольной толшиной линии. Но я нигде не видел алгоритма получения идельного матиматически сглаженного эллипса с произвольной толщиной линии. Все виденые мной способы получения такого сглаживания не математическим путем основывались на 2-х алгоритмах: Так называемый AA (рисование при большем разрешении и потом билинейная фильрация к исходному разрешению), и рисование сглаженными отрезками. Я раньше пользовался первым методом. Фотошоп по все видимости тоже пользуется им, но с некоторой оптимизацией, участки, сглаживание которых не нужно, не попадают под фильтрацию. Как я понял, в GDI+ и agg используется второй.

Здесь сравнительный скриншот разных моих изысков в этй области и фотошопа:
http://homm86.narod.ru/files/myellipse-new.png

PS. БОЛЬШОЕ спасибо DM, в котором по видимому есть автосейв сообщений, без него это сообщение стало бы намного короче.

> Но при расчете эллипса вывод это дело 10-е, важнее математика.
>  

Математика для меня не проблема, здесь я хоть могу крутить - вертеть - придумывать. А вот сделать быстрее вывод похоже невозможно.

Алгоритмы то все у меня есть, кроме пожалуй сглаженного эллипса с произвольной толщиной линии и заливкой. Но впринципе в книгах описан - сделать можно будет.

> [30] DVM ©   (22.01.08 22:28)
> Но впринципе в книгах описан - сделать можно будет.

Проверь, математические ли там алгоритмы, а не то, что я описал?

> homm ©  

да стандартный метод Wu, основанный на вычислении площади трапеции.

вот результат кстати

http://dvmuratov.narod.ru/aa.png

> [32] DVM ©   (22.01.08 22:35)
> да стандартный метод Wu, основанный на вычислении площади
> трапеции.
>
> вот результат кстати
>
> http://dvmuratov.narod.ru/aa.png

До такого, как я уже сказал, я и сам дошел :) Ты кажется говорил об алгоритме с произвольной толщиной линии.

> Ты кажется говорил об алгоритме с произвольной толщиной
> линии.

Я же наоборот говорил, что кроме него все есть.

> homm ©

Слушай, а может рисовать вложенные эллипсы, а между ними пространство залить?

Хотя не, не вложатся они нормально один в другой. Чем больше сплющен эллипс, тем более различаться по толщине будет граница.

> [35] DVM ©   (22.01.08 22:44)
> Слушай, а может рисовать вложенные эллипсы, а между ними
> пространство залить?

Наивный :)


> [36] DVM ©   (22.01.08 22:50)

Угу.

> [28] DVM ©   (22.01.08 22:18)
> Я не думаю, я попробовал.

Ну вот я попробовал:



Вариант1: 547 мс
Вариант2: 842 мс
А теперь обрати внимание, что первый вариант выполняется в цикле 50 раз, а второй только 1 :) Разница примерно в 80 раз. Уж не знаю, как ты так мерил.

> homm ©

Ты не забывай, что алгоритм Wu не перебирает все пикселы прямоугольника, в который вписан в эллипс. Берется сравнительно небольшое число точек. Твой пример не подходит совсем.