Как оптимизировать определение границ произвольной фигуры ?

[Снег Север]

учить opengl. Или вулкан,

Интересно, что быстрее: нарисовать и определить рект из картинки с помощью opengl или вулкан, либо взять "готовый" рект из скрипта?
Вот в чём фишка, мытарств, с изучением opengl или вулкан, для вычисления ректов...

Быстрее - в каком смысле? В смысле написать код для одного случая, или в смысле обрабатывать много-мегабайтные изображения много раз?
Подсказка - сейчас просто не существует сколько-нибудь серьезных графических редакторов, которые бы не использовали графическое API и процессор видеокарты. Так что ответ очевиден.

[zub]

Alex2013
>>Фокус в том что в Кол ничего подобного begin/endupdate нет...
>>( То есть это "самодеятельность" LCL и возможно ее прототипа VCL)
Нда... то что ты чтото не видишь не значит что этого нет. Возможно этот механизм не выделен отдельно и у пользователя нет возможности управлять этим самомтоятельно. кол делает это автоматом.
кол это какашка мамонта, глупо принимать его за образец, а lcl\vcl называть самодеятельностью.
Топик уже смотрится глупо. завязывай.

[vitaly_l]

Так что ответ очевиден.

Я этого и не оспариваю, я юморил. Однако, вопрос подключения вулкана, всё ещё актуален, т.к. вулканский модуль я найти-то нашёл, но вулканцы, как известно народ расторопный и у них естественно описание длиннющее, а попробовать хочется. Вот бы подключить Вулкан? Точнее вот бы примерчик, запроса к вулкану и ответа от него, у программистов выцыганить на халяву, вот сюда: http://www.freepascal.ru/forum/viewtopic.php?f=32&t=14311&start=60

[Alex2013]

Alex2013
>>Фокус в том что в Кол ничего подобного begin/endupdate нет...
>>( То есть это "самодеятельность" LCL и возможно ее прототипа VCL)
Нда... то что ты чтото не видишь не значит что этого нет. Возможно этот механизм не выделен отдельно и у пользователя нет возможности управлять этим самомтоятельно. кол делает это автоматом.кол это какашка мамонта, глупо принимать его за образец, а lcl\vcl называть самодеятельностью.

Просто в кол полная поддержка Tbitmap на уровне данных плюс отсутствие "кросплатформенных изошрений"
"Кол" это КОЛ библиотека сугубо под свою задачу (Сделать размер исполняемого файла как можно меньше ).
И в этом он силен !(ну есть еще дополнение Коллапс но это же явно перебор) Абстрактная нестабильность при разработке свершено не влияет на возможность писать вполне стабильные программы.. Бывает полезна, иногда.... Все ни больше ни меньше . А про то что LCL "самодеятельность" ну так это точно факт ...
Посмотри даже примеры к Лазарусу и прослезись сравнивания даже с набором от Кол+Мск ( я уж молчу про документированность )
Да в целом стабильно но это "в целом" такая температура по больнице .... что "Карл литрами пьет валерьянку " стоит только слезть со "светлого пути" чуть в сторону .

[Pavia]

ко, вопрос подключения вулкана, всё ещё актуален, т.к. вулканский модуль я найти-то нашёл, но вулканцы, как известно народ расторопный и у них естественно описание длиннющее, а попробовать хочется. Вот бы подключить Вулкан? Точнее вот бы примерчик, запроса к вулкану и ответа от него, у программистов выцыганить на халяву, вот сюда:

Я бы на вашем месте присмотрелся бы к DirectCompute.
Там всё чётко. Создаем входной буфер создаем буфер с параметрами создаем буфер для кода и буфер для результата.
Создаем буфер в ОЗУ переносим данные в видео память. Говорим на сколько потоков разбить наш массив данных. При этом у нас 3 размерности X,Y,Z.
И ещё в самом HLSL можно работать с пикселями как единым целым так и с отдельными компонентами A, R, G, B.

[vitaly_l]

Я бы на вашем месте присмотрелся бы к DirectCompute.
Там всё чётко.

Я когда читал, про все эти штуки, то увидел что, даже OpenGL стали использовать / рекламировать вулкан. Что-то у Вулканцев, получилось сделать ТАКОЕ, что смогло понравиться разработчикам OpenGL Больше чем их собственные разработки. При этом, OpenGL - вполне умеет всё, то, что вы предлагаете взять в DirectCompute. И для OpenGL - уже есть готовые заготовки и их очень просто подключить в Лазарусе. А вот вулканцы, дают ещё немного больше возможностей, т.к. заточены не только под графику. Снег северный физик, наверняка знает как подключить Вулканцев к Лазарусу, если его (или кого нить ещё) удастся растрясти на пример, то будет немного халявы, т.к. в принципе ВОЗМОЖНО примеры есть в инете (я ещё не искал).

[Alex2013]

В одном есть ScanLine в другом нет ... Разницы ноль ... только со ScanLine код опрятнее смотрится и все .

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

Но возвращаясь к ректам, их всё равно посчитать будет быстрее. Потому что там всего, 400 итераций, вместо 100 000 000. А если эти 400 итераций вычислять с помощью вулкана... то... вычисления будут ОЧЕНЬ-ОЧЕНЬ быстрыми .

.

Еще раз объясняю : сказка в том, что переход от Canvas.Pixels[x,y](причем на чтение! ) к ScanLine дало прямо таки оглушительный "эффект ускорения" (на порядок как минимум ! ) Что и сподвигло меня на дальнейшие поиски способов оптимизации ...
А считать сдвиги строк чаще всего все равно нужно и по идее обход всех линий может и не понадобится ....( в теории ты разумеется прав... но читаемость кода очень важна, а то сегодня заметил совершенно глупую ошибку.... Долго и уныло терзавшую мои нервы именно потому, что пошли всякие "ручные вычисления смещений " там где это не нужно (взял и умножил размер строки в байтах на количество байт в пискле ...Ага! и самое печальное что все вроде как РАБОТАЛО но стоило сойти "с рельсы" случайного удачного "стечения данных" как полезли "непонятные" исключения )
Зы
Кстати скорость прорисовки наконец измерения в цифрах уже почти реально радует !
(разницы между оконным режимом и расширением практически нет плюс несильно уменьшается при увеличении количества фигур одна фигура (порядок "поедания CPU@ 0.0020-0.0050с десять 0.0040-0069с .))
Первая загрузка из файла разумеется медленней но дальше все если не "летает" то быстро ходит, что уже почти устраивает в рамках данного проекта .

[zub]

10? Просто десять? Даже не 10 тысяч?

[Alex2013]

10? Просто десять? Даже не 10 тысяч?

Десять смотря отчего ... пять секунд (на примере средней тяжести ) ДО и и менее полвины секунды ПОСЛЕ разница вполне себе впечатляющая ....

[vitaly_l]

10? Просто десять? Даже не 10 тысяч?

А по моему, для данной задачи, вполне нормальный результат. Вряд ли объектов будет больше 1000, а при 1000 задержка меньше секунды, очень жаже вполне приличный результат.

[Alex2013]

10? Просто десять? Даже не 10 тысяч?

А по моему, для данной задачи, вполне нормальный результат. Вряд ли объектов будет больше 1000, а при 1000 задержка меньше секунды, очень жаже вполне приличный результат.

Вся проблема в том, что замечена очень сильная зависимость от размеров рабочего поля ... Непропорциональная !
Да и элементы там разные есть ... (Растровая картинка или градиент всю страницу например могут сожрать от 50 до 100 мс даже в одиночку и это не придел )
А тут еще совершенно тупые тормоза с очисткой фона для прорисовки следующей фигуры ...
Почти идеальным случаем был бы вариант когда в один проход картинка рисуется а в другой стирается ....
Но фокусы с NotХоr для метофайлов почему-то не срабатывают ....
Зы
И главное прорисовка это одно а поиск границ совсем другое .... Прорисовка в целом вполне устраивает

[Pavia]

А по моему, для данной задачи, вполне нормальный результат. Вряд ли объектов будет больше 1000, а при 1000 задержка меньше секунды, очень жаже вполне приличный результат.

Смонтировать внимательнее сколько у него ноликов. Он до 1000 не дотягивает - это раз.
Да и по времени гостированных 0٫1 с укладывается только при 20 штуках.

Добавлено спустя 2 минуты 37 секунд:
Re: Как оптимизировать определение границ произвольной фигуры ?

Непропорциональная !

Вам уже писали про Scanline, выкинте его. Будет ещё быстрее.

[vitaly_l]

Смонтировать внимательнее сколько у него ноликов. Он до 1000 не дотягивает - это раз.
Да и по времени гостированных 0٫1 с укладывается только при 20 штуках.

Кстати, так ведь это же художникам на руку!!!
Потому что теперь, у Alex2013 есть только один выход : подключить Вулканцевский код!
И заодно ОБЯЗАТЕЛЬНО выложить пример подключения в этот топик

[Alex2013]

А по моему, для данной задачи, вполне нормальный результат. Вряд ли объектов будет больше 1000, а при 1000 задержка меньше секунды, очень жаже вполне приличный результат.

Смонтировать внимательнее сколько у него ноликов. Он до 1000 не дотягивает - это раз.
Да и по времени гостированных 0٫1 с укладывается только при 20 штуках.

Добавлено спустя 2 минуты 37 секунд:
Re: Как оптимизировать определение границ произвольной фигуры ?

Непропорциональная !

Вам уже писали про Scanline, выкинте его. Будет ещё быстрее.

Так уж почти убрал ...
(В общем нужно будет выложить тестовую версию (С циферками "телеметрии" )что-бы не толочь вводу в ступе. )
Но основной "двигатель торможения" в очистке фона .

Нужно или оптимизировать сам поиск границ настолько что-бы можно было его применять при каждой итерации получая рект для закраски ( сейчас даже если кликнули в фон прокручивается весь список фигур но границы функция считает только один раз при "прямом попадании")

Или найти способ очень быстрой очистки ...
Например через перерисовку битмапа им самим с помощью BitBlt c некой логической операцией .

[Снег Север]

Точнее вот бы примерчик, запроса к вулкану и ответа от него

Посмотрите тут:
http://vbomesh.blogspot.co.il/2016/04/d ... ulkan.html