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

[Alex2013]

Вот три функции, у которых рект находится внутри функции или придётся считать:

Код: Выделить всё

AddFunction(@DRW_OutText,'Procedure DRW_OutText(X,Y:Longint;S:String);');
AddFunction(@DRW_MoveTo,'Procedure DRW_MoveTo(X,y:LongInt);');
AddFunction(@DRW_LineTo,'Procedure DRW_LineTo(X,y:LongInt);' );


С другой стороны, в 90% функций, которые Вы привели, вы передаёте функциям уже готовый рект, вот они:

Код: Выделить всё

AddFunction(@Drw_LoadIMG,'Procedure Drw_LoadIMG(X,Y,x1,y1:LongInt;N:String);');
AddFunction(@DRW_VGradientFill,'Procedure DRW_VGradientFill(X,y,X1,Y1,C1,c2:LongInt);');
AddFunction(@DRW_HGradientFill,'Procedure DRW_HGradientFill(X,y,X1,Y1,C1,c2:LongInt);');
AddFunction(@DRW_Rect,'Procedure DRW_FillRect(X,y,X1,Y1:LongInt);');
AddFunction(@DRW_Rect,'Procedure DRW_Rect(X,y,X1,Y1:LongInt);' );
AddFunction(@DRW_Elips,'Procedure DRW_Elips(X,y,X1,Y1:LongInt);');
AddFunction(@DRW_LINE,'Procedure DRW_Line(X,y,X1,Y1:LongInt);');


Соответственно, все эти ректы, вы где-то храните (в каком-то списке или файле),
почему вы оттуда - не берёте значения ректов, а вместо этого повторно их высчитываете?
Или объекты рисуются друг на друге, а потом 10-ть объектов, вы считаете одной фигурой?

Но даже при таких обстоятельствах, высчитать наибольший рект из 10-ти складываемых ректов,
быстрее по времени и менее затратно для процессора, если брать ректы прямо из списка/файла в котором Вы храните данные для скриптов.

На самом деле безусловно пофигу, т.к. разница в скорости при громадном числе фигур максимум 1 или 20 секунд.


.

Снова не понял в чем фишка ... Я предаю в скрипт набор функций ..
Что рисует их помощью скрипт(по сути подпрограмма на упрощенном диалекте паскаля ) по неким исходным данным, нельзя определить заранее (и размер тоже ) а связь изображения с данными в команде (данные сохраняются в виде изменяемого списка неких абстрактных команд ) весьма условна ( Легко представить например элемент "глобальную рамку" у которого вообще нет связи даже с начальной точкой но есть поля цвет толщина и стиль )

Для каждой команды есть свой скрипт(и даже не один) .
Многие могут иметь в данных размеры но не все

Код: Выделить всё

FORM $FF $A2045/F1/Login 44 48-308 357
OUTTEXT $FFFF $A2045/101/10/Arial/_Авторизиризация_ 56 60 END
OUTTEXT $FFFFFF $A2045/0/11/default/Логин_: 78 115 END
FORM_EDIT 0 16777215F1Имя_ползьзователя____Edittext 77 139 END
OUTTEXT $FFFFFF $A2045/0/11/default/Пароль:_ 78 164 END
FORM_EDIT_PSW 0 16777215F1*******************************Editpassword 76 187 END
FORM_CHECKBOX 0 16777215F1Запомнить_CheckBoxoff 162 218 END
FORM_BUTTON 0 16777215F1____ОКButtonsubmit 89 266 END
FORM_BUTTON 0 16777215F1ОтменаButtonRESET 177 266 END
PAGE_SETUP [f.htm]  [16777215]  []  []  [<ZZZ>]


RAPHAEL_KONTUR 65280 16777215 48 215 16 264 16 264 262 265 262 265 242 215 242 215 END
RAPHAEL_KONTUR 65280 16777215 50 217 18 266 18 266 264 267 264 267 244 217 244 217 END
RAPHAEL_KONTUR 65280 16777215 46 213 14 262 14 262 260 263 260 263 240 213 240 213 END

Произвольный замкнутый контур . Где у него размер ? (Специально вычислить можно но глобально, не зная, что делает конкретная команда ? Шишь !)

RAPHAEL_KUB 0 16777215 448 44-579 204
RAPHAEL_KUB 255 16777215 448 44-581 206
RAPHAEL_KUB 0 16777215 377 49-508 209
RAPHAEL_KUB 255 16777215 377 49-510 211

У куба "размер" вроде есть но для его рисования данные используются иначе ....

[vitaly_l]

по сути подпрограмма на упрощенном диалекте паскаля

Круто - художники заценили!
Битмапку можно "сжать" с помощью палитры, правда тогда будет всего 256 цветов, но зато скорость обработки повысится ещё на 88%.

.

[Alex2013]

Прилепляемая скорость перерисовки достигается применением списка метафайлов это еще круче ! (память не жрет ) "Круче только горы!" ...
Но главное в генерации HTML-кода . (Иначе смысла весь этот "огород" городить разумеется нет )

[zub]

>>Анимированая демка уже своим существованием показывает изрядный запас скорости
Да уж. На моем i7 нету там никакого запаса. Тормоза и жрачка ресурсов на ровном месте есть, это да.

>> что задержка реакции от 50 до 200 мс будет почти не заметна )
Ловко рассуждаешь, поставь ка себе задержку 200 мс на каждый клик, да еще с зависимостью от наполнения экрана.
Эта операция сделаная по нормальному - бесплатна.

>>Но я уже еще кое-что "подшаманил"
Ты занимаешся ерундой.

>> Но побудительные мотивы заменить все это "грамадьё планов" ОДНОЙ функцией совершенно очевидны ...
Ты бы хотябы один замер скорости сделал, прежде чем фантазировать

Добавлено спустя 15 минут 40 секунд:
Re: Как оптимизировать определение границ произвольной фигуры ?
>>кусок списка регистрации функций для передачи в скрипт
>>...
>>И это возможно еще не финал ....
Пара десятков функций... Ты думаешь это много?

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

[Pavia]

zub

[zub]

не, обычно пишу сюда и иду спать))

[Alex2013]

Тихо в лесу ...

В общем вчера в голове было пусто но руки чесались что-то еще "наоптимизировать"...

По результатам :
При размере окна по умолчанию единичный тык даже с "тяжелыми "(сотни элементов в макете веб страницы ) примерами срабатывает за время то 0.3 с до 0.6 c...
А вот с максимизатцией окна до Фул-ЭйчДи и дальше ( растягиваю на второй экран ) все печально от 1.5 до 2.5 с... (Хотя с простыми макетами задержка заметно меньше )

Гарантированно известно что основной тормоз в очистке временного битмапа ....
Пока лучший способ заполнение заранее созданным пустым битмапом через BitBlt .. (то еще изощрение... ) Но факт что это реально самый быстрый способ заполнения.
Надежды на работу с RawImage и ScanLine в режиме записи пока не оправдались ...
Кстати !
Оказывается прямой доступ к данным изображения по молчанию установлен в режим "только чтение" (как подобное можно сделать с массивом данных в памяти даже я не представляю! )
...и что-бы включить запись нужно в начале блока кода где происходит прямое обращение к растру в обязательном порядке вызвать BeginUpdate а в конце EndUpdate ;

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

[Лекс Айрин]

Оказывается прямой доступ к данным изображения по молчанию установлен в режим "только чтение" (как подобное можно сделать с массивом данных в памяти даже я не представляю! )

Элементарно. Выставляются соответствующие атрибуты сегмента данных. Причем, если правильно поиграть сегментами и сегментными регистрами, то можно сделать чтобы выполнялись данные и записывалось в код. Правда, мало кому это требуется. Видимо, функции BeginUpdate и EndUpdate меняют права сегментного регистра.

[zub]

>>Элементарно.
Без обид.На форуме количество фантазеров зашкаливает.
Когда чтото незнаешь - лучше промолчать, когда догадки - обозначить что это ИМХО.

Alex2013
Не делай так как тебе советуют низачто. пусть на и7 будут секундные лаги... пофиг
>>Оказывается прямой доступ к данным изображения по молчанию установлен в режим "только чтение"

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

Книжек чтоли какихнибудь почитай - как оно работает

[Лекс Айрин]

Без обид.На форуме количество фантазеров зашкаливает.
Когда чтото незнаешь - лучше промолчать, когда догадки - обозначить что это ИМХО.

Это НЕ догадки. Это результат чтения даташитов по процессорам intel. Пытался понять как работает компилятор и вообще все это на низком уровне. Кстати, там было все подробно расписано. В том числе, как делать самомодифицируемый код и как при этом настраивать сегментные регистры. Даже понятнее чем описание формата PE EXE. Другое дело, что обычный программист всего этого не видит и ему это вредно видеть.

[vitaly_l]

Книжек чтоли какихнибудь почитай - как оно работает

Я тут на другом форуме, прочитал что, указатели, вот такие фигульки: ^ - ненужны в Lazaruse и Дельфи, потому что, они автоматом создаются при создании динамического или статического массива. И типа, все кто их создаёт - делают неправильно... Чувак на том форуме явно гонит или в его словах есть суть истины и правильнее с массивами работать без указателей?

Кстати !
Оказывается прямой доступ к данным изображения по молчанию установлен в режим "только чтение" (как подобное можно сделать с массивом данных в памяти даже я не представляю!

Вообще-то, там где-то есть Data и в ней хранится нормальный одномерный массив. А все эти сканлайны, это уже соединение через модем. Но это всё равно - не сильно ускорит обработку, потому что, 100 объектов, нарисовать... потом просканировать - процессору явно тяжко там. Можно конечно подключить ресурсы видеокарты, тогда - это ускорится раз в 50... Но по моему, проще брать ректы, прямо из скрипта, но понятное дело придётся день потратить на написание ректо-дешифратора. Поэтому, топикстартеру, конечно же лучше, ещё недельку по...эээ...мучиться со сканлайном, чем потратить день на вычисление чёртовых ректов прямо из скриптов.

[zub]

Програмисту на паскале читать даташиты незачем (только для общего развития), это совсем не про пиксели и доступ к ним. Горазод поучительней будет - почитать как работают проперти и поотлаживать что там внутри BeginUpdate\EndUpdate.

>>Чувак на том форуме явно гонит или в его словах есть суть истины и правильнее с массивами работать без указателей?
конечно гонит, но и суть конечно есть)) ВСЁ ХОРОШО В МЕРУ И ПОДЕЛУ

[Pavia]

Я тут на другом форуме, прочитал что, указатели, вот такие фигульки: ^ - ненужны в Lazaruse и Дельфи, потому что, они автоматом создаются при создании динамического или статического массива. И типа, все кто их создаёт - делают неправильно... Чувак на том форуме явно гонит или в его словах есть суть истины и правильнее с массивами работать без указателей?

В Delphi есть автоматическое разиминовывание(^) указателей.
А вот во FreePascale'е такой фишке нет.

[zub]

>>А вот во FreePascale'е такой фишке нет
1. {$MODE DELPHI}
2. "авторазименование" - сахарок для програмиста, сути никак не меняет

[Alex2013]

Кстати !
Оказывается прямой доступ к данным изображения по молчанию установлен в режим "только чтение" (как подобное можно сделать с массивом данных в памяти даже я не представляю!

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

Ага а ты попробуй в это Дата записать свое "батоне" ...
Без вызова вначале BeginUpdate а в конце EndUpdate .. "Байто раздирающие зрелище !" "Я его ем ем, а он все круглый ..." (с)Классика детских страшилок
Причем даже если поучаешь ссылку от чрез ScanLine выше BeginUpdate она того НЕ РАБОТАЕТ ! (Не "магия-шмагия" но "мистика" определенно ! )
Вот кусок тестового кода ...
(И повторяю у меня вообще рабочий битмар вообще никуда не выводится просто создается в памяти и там-же "гибнет"
В тесте вывод сделан для наглядности )

Код: Выделить всё

procedure TRawForm.Button1Click(Sender: TObject);
begin
Image1.Picture.Bitmap.BeginUpdate;

   With  Image1.Picture.Bitmap.RawImage do begin

     FillByte(Data^,  DataSize  ,60);//Заполнение через RawImage
   
end;
   Image1.Picture.Bitmap.EndUpdate;
   Image1.Refresh;

end;

procedure TRawForm.Button2Click(Sender: TObject);
Type
TL=Array[0..2] of Byte;
var
PL:^TL;
I:Integer;
B:TBitmap;

begin
b:=Image1.Picture.Bitmap;
For i:=0 to B.Width-1 do
B.Canvas.Pixels [I,Image1.Height div 2+10]:=255;
//  PL:= B.ScanLine[Image1.Height div 2];// Так НЕ работает
B.BeginUpdate;
  PL:= B.ScanLine[Image1.Height div 2];// Так работает 
  For i:=0 to B.Width-1 do begin
    pl^[i*3]:=0;pl^[i*3+1]:=255;pl^[i*3+2]:=0;
   end;
  PL:= B.ScanLine[Image1.Height div 2+5];
   FillChar(PL^,(B.Width-1)*3,0);
B.EndUpdate;
Image1.Refresh;
end;
procedure TRawForm.FormCreate(Sender: TObject);
begin
    Image1.Picture.Bitmap.SetSize(Image1.Width,Image1.Height);
    Image1.Picture.Bitmap.Canvas.Pen.Color:=0;
    Image1.Picture.Bitmap.Canvas.Brush.Color:=$ffffff;
    Image1.Picture.Bitmap.Canvas.FillRect(0,0,Image1.Width-1,Image1.Height-1);
    Image1.Picture.Bitmap.Canvas.Line(1,1,Image1.Width-10,Image1.Height-10);
    Image1.Picture.Bitmap.Canvas.Line(1,Image1.Width-10,Image1.Height-10,1);
    Image1.Refresh;
end;



Но это всё равно - не сильно ускорит обработку, потому что, 100 объектов, нарисовать... потом просканировать - процессору явно тяжко там. Можно конечно подключить ресурсы видеокарты, тогда - это ускорится раз в 50... Но по моему, проще брать ректы, прямо из скрипта, но понятное дело придётся день потратить на написание ректо-дешифратора. Поэтому, топикстартеру, конечно же лучше, ещё недельку по...эээ...мучиться со сканлайном, чем потратить день на вычисление чёртовых ректов прямо из скриптов.

Да разумеется, но фокус в том, что теоретически можно достичь скорости прорисовки ... И этого будет достаточно ! Подумаешь проблема при при клике лишний раз вызвать быструю перерисовку изображения (то есть уже не через скрипты а через список "полуфабрикатов-метафайлов" ) Если сама перерисовка будет вызывать проблемы то их нужно "лечить" совсем в другом участке кода ...
Зы
Без поиска границ определение номера фигуры по скрости было почти удовлетворительным, но дело в том что при "оконтуривании границы" задержка стала отчетливо видна ...
+ собственно время на определение границ текущей фигуры( его нужно совсем не много ) ...

Кстати мысль: а что если "раскрыть циклы" и после изменения фигуры потихоньку считать границы в фоновом режиме