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

[olegy123]

Да, но старые технологии не отмирают до последнего. Например, несмотря на шествие форточек, ДОС, как рок-н-ролл, еще жив. Да и, несмотря на распространение ООП, никто не запрещает писать в старом, функциональном стиле. И таких примеров куча...

Согласен.. Даже больше скажу - что самое буйное развитие программ было в 80х~90х прошлого столетия -(количество открытий/программисты).. Все что сейчас считается нормой: ввод пальцем-татчскрин(пионером вовсе не была эпйл, а была майкрософт в 90х).. даже распознование голоса было уже доступно в 90х на ПК..
Отличие только в том стоимость чипа.. чипы стали более производительными и дешевыми.

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

Что бы мне хотелось - так это Растровая графика на CUDA,OpenCL. Нет не по причине того что нельзя этого сделать.. просто этого еще никто не делал.
Математика - есть, видео - есть.. даже бирживые операции там кодят.. а растровой графике - нет.

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

Вначале испортили, а потом закрыли. Буржуины.

Там Стив стал выступать что мол какой позор использовать флэш..

А движок у них - реально офигенный.
Ещё точнее: идеи - там заложены офигенные!
HTML5 - позволяет реализовать разве что, ПОЛОВИНУ из них и то... со сложным написанием JS.

Во-во, замена функционала Flash на Html5 уже 10 лет идет.. Вот чем отличаются один-два идейных прогера.. от тысячи безыдейных высокооплачиваемых специалистов..

[Лекс Айрин]

самое буйное развитие программ было в 80х~90х прошлого столетия

В 60-70хх тоже было неплохо... найденные тогда методы используются до сих пор.

Все что сейчас считается нормой: ввод пальцем-татчскрин(пионером вовсе не была эпйл, а была майкрософт в 90х).. даже распознование голоса было уже доступно в 90х на ПК..

Вообще, пионер в этом деле лаборатория MIT. Сейчас они занимаются нейроинтерфейсом. Так что ждем-с нейроконтакты.

Что бы мне хотелось - так это Растровая графика на CUDA,OpenCL.

А смысл? Это же все, насколько я помню, прекрасно делается на шейдерах без обмана видеокарты. Или ты хочешь полноценный редактор сделать?

[olegy123]

В 60-70хх тоже было неплохо... найденные тогда методы используются до сих пор.

Это не я, это западные профи так говорят. Было обсуждение - сравнение с сегодняшними вызовами.., что мол в 80х был буйный рост открытий в области IT (написания программ).. Были люди которые реально делали большие дела..
Например тот же Ситв Джобс, тот же сэр Синклер - который реально сделал массовый домашний дешевый компьютер(и из-за этого дали титул сэра). Кстати очень интересно его история.. он общался и конкурировал с людьми которые потом организовали контору ARM..
Так вот по сегодняшнему времени говорили, мол идем не туда.. нарожали джава-прогеров которые работают в основном в финансовом сфере.. а некоторые даже стали утверждать что джава-прогеры - это хреновые прогеры..

Добавлено спустя 1 минуту 49 секунд:
Re: Как оптимизировать определение границ произвольной фигуры ?
У них там джава, у нас тут 1Ска..

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

Или ты хочешь полноценный редактор сделать?

Agg+CUDA = то что нужно.. типа bgrabitmap на аппаратном уровне..

[Лекс Айрин]

Это не я, это западные профи так говорят.

это и понятно... как только появились массовые компы, так отрасль и начала бурно развиваться.

Как только появится что-то реально новое, будет следующий скачок. Например, полноценные виртуальные миры, расширенная реальность, бытовые роботы, которых можно будет купить в магазине, регулярные полеты в космос, прикладное терраформирование и генные присадки... вариантов куча. И заранее не скажешь какой из них выстрелит.

[vitaly_l]

Во-во, замена функционала Flash на Html5 уже 10 лет идет.. Вот чем отличаются один-два идейных прогера.. от тысячи безыдейных высокооплачиваемых специалистов..

Адоба позарилась на халяву срубить денег, а в реальности, людей, которые одновременно: рисуют и кодят - очень мало и проект Flash in Adobe, скорее всего - 100% не окупал себя. А громадный штат для Flash in Adobe - им содержать-то нужно. Так что, скорее всего, всё упирается в деньги.

.

[Alex2013]

2 ZUB: Прочти все-же о чем разговор идет .... А то снова конфуз может получится.
Я задал конкретный вопрос и УЖЕ частично получил на него нужные ответы или в процессе обсуждения в режиме "мозгового штурма" сам пришел к нужным ответам .( За что кстати, всем спасибо !)

Alex2013
>>Но мне интересует: нет ли чисто АЛГОРИТМИЧЕСКОЙ ОПТИМИЗАЦИИ подобного поиска ?
Поднимай свои старые топики. думаешь с тех времен придумались новые алгоритмы?

Думал что новые люди могли на форум прийти или кто-то умных книг например начитался ...
(Кроме того вопрос действительно весьма конкретный и здесь я ничего подобного еще спрашивал .
(Тоже было и по теме "Как ускорить прорисовку векторной графики ?" ты ведь если я верно понял на нее намекаешь ? )

Alex2013
>>(Что в LCL такого в канвас напихали что ПРОСТОЙ ДОСТУП К ПИКСЕЛЮ взывает настолько дикий тормоз ?)
Нету никакого простого доступа к пикселю. Считай что пиксели лежат на другом компе в другой стране, а связь по зухелю 9600бод.
За всякие сканлайны и гетпиксели надо по ручкам лупить.

В Битмапе который никто даже выводить на экран не собирается ? Нет прямого доступа к участку обычной памяти ? Дело в том, что он как раз есть (Через тот же TBitmap.ScanLine или RawImage ) но вот почему "более стандартный" доступ через псевдомасив Canvas.Pixels в разы медленней (причем на чтение !) для меня загадка ...

Зы
Кстати, наверное есть способ БЫСТРО проверить всю "СканЛинию" на заполнение фоновым цветом ...
(Что-то вроде сравнения строка_А = строка_Б )
Что предложите ? Мне что-то все варианты " с явно лишним кодом" в голову лезут ...


Добавлено спустя 38 минут 9 секунд:

Это не я, это западные профи так говорят.

это и понятно... как только появились массовые компы, так отрасль и начала бурно развиваться.

Как только появится что-то реально новое, будет следующий скачок. Например, полноценные виртуальные миры, расширенная реальность, бытовые роботы, которых можно будет купить в магазине, регулярные полеты в космос, прикладное терраформирование и генные присадки... вариантов куча. И заранее не скажешь какой из них выстрелит.

Угу "нанотех и все все все " ...
Но мене кажется что стоит заранее подумать куда может ветер подуть тем более в такой области как программирование ...
Вариантов ведь сточки зрения ПРОГРАММИСТОВ не так уж и много :
1 Нейросети и нечеткая логика
2 Микропрограммы ( "микро-кластерное программирование" что-то типа того же CUDA ? )
3 Алгоритмы обработки изображений и разное распознание ( необязательно нейро-сетевое)
4 Фрактальное построение 3д-миров и моделей (В идеале эвристика по словесному описанию )
5 Облачные технологии "в пределе" ( например программа сама ищет в интернете способы собственной оптимизации или производит "самопортирования" или строит дизайн сайтов на основе неизвестных на момент ее выхода технологий + классические функции:
распределение вычислений и облачные хранилища )
6 Не навязчивые элементы ИИ в плане построения диалоговых интерфейсов
7 Использование "Закона Мура" (Закладывать заранее функции которые начнут работать при увеличении производительности например через год-два после Релиза )
8 Квантовые алгоритмы .
9 Адаптивное веб-программирование (или нечто похожее но уже на уровне VR-AR )
....

Добавлено спустя 44 минуты 40 секунд:

т.е. вы считаете что алекс ищет тег, а не координаты фигуры?

TRect он ищет (по сути: координаты тегов) и номер I. И никогда не задумывался как работает векторная графика.

pupsik, он просто не понял для чего ищут описывающий фигуру прямоугольник. Я тут еще пошла фигня с тесселяцией и пр.

Жуть! И это наши программисты? Они даже код прочесть не могут... Теперь понятно почему, ракеты падают.

.

Брр... "Без меня меня женили"..
Теги у меня строятся по списку "команд" (что-то вроде ну очень примитивного AutoLISP-а ) и там все с координатами нормально .
Все "эпохальное действие" поиска границ нужно просто чтобы было видно при клике куда он попал и где кончается текущая фигура
(которая может только краем выглядывать из под другой )
То есть мне это "квадратик вокруг кубика "
(см скриншот)
НИГДЕ дальше не нужен
я даже масштабирование фигур собираюсь по другим данным делать
(Просто собираюсь масштабные коэффициенты по осям Х и Y для каждой фигуры вести без относительно к текущим размерам )

[zub]

>>Кроме того вопрос действительно весьма конкретный и здесь я ничего подобного еще спрашивал .
Мой парсер тебя тежело понимает.
>>И так добрался я до выделения прямоугольника текущей фигуры по клику мыши .
Я вижу тут 2 варианта:
1 - найти границу чегото нарисованого на растре
2 - найти то что попало в начерченый мышкой прямоугольник выделения - типа как ты в редакторе форм ыаделяешь несколько объектов.

Если 1 - это какаято ахинея - зачем ползать по пикселям если ты сам это толькочто рисовал и знаешь все координаты? если это какойто левый растр типа фотки и надо чтото на нем найти - лучше идти на какойнить CUDA форум
Если 2 - то это вполне типичная задача для векторного редактора. ползать по пикселям для ее решения тоже ерунда, она гораздо быстрее решается "математически"

>>Тоже было и по теме "Как ускорить прорисовку векторной графики ?" ты ведь если я верно понял на нее намекаешь ?
Была тема про выделение примитива мышью, как она называлась тебе видней

>>Кстати, наверное есть способ БЫСТРО проверить всю "СканЛинию" на заполнение фоновым цветом ...
>>(Что-то вроде сравнения строка_А = строка_Б )
Ты уже догони что проблема не в сравнении - им можно пренебречь, а в получении этих значений от графической системы. Обработка растров на цпу уже давно не актуально

>>Дело в том, что он как раз есть (Через тот же TBitmap.ScanLine или RawImage ) но вот почему "более стандартный" доступ через псевдомасив Canvas.Pixels в разы медленней (причем на чтение !) для меня загадка ...
Ну если загадка... прими как данность и не делай так.

вот просто пораскинь мозгами...
твой макрос-шмакрос рисует линию от 0,0 до 10000,10000 сколько пикселей ты перелопатишь? зачем это зависит от размера линии?
если 1 - а для получения границ математически нужно всего несколько сравнений независимо от размера растра
если 2 - определение пересечения или попадания линии в прямоугольную область тоже делается несколькими элементарными действиями и от размера растра не зависит

В упомянутой мной теме (на которую ссылаюсь) был перл про пишется как слышится. Завязывай уже с этим

[olegy123]

Обработка растров на цпу уже давно не актуально

Немого добавлю.
Последние процессоры от Intel уже включают в себя работу OpenCL(CUDA)..
Почему их не используют? Потому что еще мало инструментария написано для работы с этими вещами.. но возможно скоро все изменится..

[vitaly_l]

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

Именно об этом вам и говорят!!! Только делается такой поиск, с помощью TRect, а не ScanLine. И действительно, точно также ищутся и теги на html страницах. И масштабирование, как ни странно проще делать с помощью TRect. А TRect - нужно закладывать при создании фигуры, а не вычислять при каждом клике. Это вы можете понять? Вам все, только это и хотят сказать: ДЕЛАЙТЕ TRect - ЗАРАНЕЕ, а не вычисляйте его при каждом клике. Впрочем - решайте сами, вам видней.

[Лекс Айрин]

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

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

[vitaly_l]

Просто собираюсь масштабные коэффициенты по осям Х и Y для каждой фигуры вести без относительно к текущим размерам

Тут важно уловить и понять фразу: СОЗДАВАЙТЕ TRect - сразу (ЗАРАНЕЕ), при создании фигуры и подправляйте при масштабировании, а не вычисляйте при клике. И я не уверен..., но скорее всего, вы вообще выкинете свою функцию со сканлайнами... Потому что, время на "вычисление" TRect - будет мгновенным.

[Pavia]

Рисуешь примитивы только в место цвета используешь порядковый номер.
Что-бы узнать по какому примитиву нажали надо просто считать значение пикселя, сложность алгоритма O(1).

Второй способ хранить TRect для каждой фигуры.
Перебираешь все фигуры и проверяешь PointInRect.
Тут можно посмотреть простой векторный редактор.

Что касается оптимизации GetPixel и SetPixel то я себе сделал класс для быстрого доступа который в 400 раз быстрее! Правда пока для Delphi.
LazyBitmap


Что касается треугольники против квадратов. Давно известно, что все 3D модели состоят из 4 угольников. Так как треугольники вызывают артефакты.
http://www.youtube.com/watch?v=k_S1INdEmdI

А средний GPU не намного быстрее среднего CPU. Раза в 4 так что стоит ли игра свеч решать вам.

[zub]

Pavia
Пометь сообщение тегом вредные советы

[vitaly_l]

Что касается треугольники против квадратов. Давно известно, что все 3D модели состоят из 4 угольников. Так как треугольники вызывают артефакты.

Ну уж неееет!!! Чувак на видео на непонятном языке, внушает неразумным, что, мол аппроксимируйте треугольники в моделях, до прямоугольников и тогда не будет лишних искажений. А здесь речь шла совсем о другом, более быстром формате 3D-движков в принципе АПРИОРИ ЗАПРЕЩАЮЩЕМ использовать треугольники (c)! Запрещающем - не потому что они искажают, а потому что, прирост в скорости 3D-движка будет на 75% ферштейн или нибельмеса? ( Это для Pavia к вопросу о сканировании и построении объектов, с помощью видео камер. )

[zub]

Pavia
Зачем ссылка на форум где нужна регистрация?