1 Насчет скорости ...
Анимированая демка уже своим существованием показывает изрядный запас скорости
( В реальной программе нужна реакция на однократный клик, а это значит, что задержка реакции от 50 до 200 мс будет почти не заметна )
Но я уже еще кое-что "подшаманил" (сделал сканирование по горизонтали так-же как и по вертикали (то есть там теперь сканирование и по иксам идет от точки клика в обе стороны ) + обнаружил что самый лютый тормоз образуется при задании размеров буферного битмапа ...ну это довольно просто поправить ... (можно использовать и так существующую "теневую страницу" ))
2 Почему не так
RF1.FastDrawFig(I,1,aRect); //Возвращает один рект и рисует фигуру ?
В принципе Zub за меня уже ответил .
Могу добавить что для получения aRect придется или :
1) Запускать при первичной сборке коллекции метафалов почти аналогичную процедуру поиска границ ...
2) Без особых гарантий добавить целый "слой слежения" в каждую процедуру передаваемую в скрипт для первичной прорисовки фигур, что не то чтобы совсем не достижимо... но сам посмотри вот кусок списка регистрации функций для передачи в скрипт
- Код: Выделить всё
// Графика
AddFunction(@DRW_SetFontParam,
'procedure DRW_SetFontParam(C,CB,BUI,FS,FN:String);');
AddFunction(@DRW_GetTextWidth,'Function DRW_GetTextWidth(S:String):longint;');
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);' );
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);');
AddFunction(@DRW_SetPenColor,'Procedure DRW_SetPenColor(C:Longint);');
AddFunction(@DRW_SetBrushColor,'Procedure DRW_SetBrushColor(C:LongInt);');
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);');
И это возможно еще не финал ....
Ну и на закуску!
+ где-то все данные "слежения за скриптом" должны собираться в этот самый
aRect + где-то нужно вести дополнительный список с проверкой актуальности данных + синхронизация данных со списком команд(теневым и основным ) + синхронизация со списками мета-файлов и вообще всеми активными действиям в редакторе ...
Возможно все не так страшно как кажется . Но побудительные мотивы заменить все это "грамадьё планов" ОДНОЙ функцией совершенно очевидны ...
3) Гибридный вариант : Рисовать локально все с точки 0,0 а выводить со смещением ...
В этом случае многое должно упростится но это тоже потребует много не совсем очевидной "работы над ошибками"
Добавлено спустя 34 минуты 30 секунд:vitaly_l писал(а):zub писал(а):Потому что процедура рисования (у Alex2013 это некий скрипт) должна быть как можно проще, и "трудности" надо решать в "движке", а не в этих процедурах. Сегодня нам понадобился габарит, завтра понадобится еще что-то - снова скрипты модифицировать?
Почему нельзя продублировать функцию?
В изначальном варианте, она будет просто рисовать, а в дубле, будет: и рисовать, и + ещё возвращать рект.
И скорость рисования сохранится и рект можно будет получать из скриптового источника, там - явно проще рект посчитать. Или нет?
Хотя, безусловно, можно сделать отдельную функцию, которая будет возвращать только рект из скриптов.
наверняка в скриптах, все ограничения заданы, типа как в ректе.
.
Ты просто загипнотизирован словом "фигура" и похоже считаешь что это просто фигура из канваса ...
Но это может быть например целый псевдослучайно нарисованный и рассчитанный по формулам фрактал
(Хоть дерево Пифагора, хоть треугольник Серпинского)
То есть в любом случае границы могу быть неопределенными (Как в том же демо-кубе, где в качестве основных исходных данных в скрипт предается некая
точка привязки которая может вообще быть вне фигуры ).