zub писал(а):Alex2013
>>Десять смотря отчего ...
Мерить скорость отрисовки 10 примитивов не имеет смысла, тут либо твой замер это одна погрешность либо твоя процедура отрисовки настолько медленна что...
Я бы на твоем месте сделал стрессовый "файл" тысяч на 10 примитивов, и на нем бы смотрел что да как.
Zub про принцип "разумной достаточности" ты явно не слышал ...
Планируемый безусловный разумный максимум 1000 элементов в макете (Можно даже явно прописать ограничение "бо нефиг" ибо уже сейчас никто не мешает разделить страницу на несколько блоков генерация идет через замену "Певдо тега " ... кстати идея!
можно вообще добывать элемент "псевдо фрейм"(суть не в названии) по типу панели в Хайасм (там чтобы редактировать панель в редакторе форм нужно в нее "зайти" и это отсекает все элементы "выше") картинку для показа можно получать отдельно один раз при загрузке или изменении ) ...
Если нужно больше по любому нужно как-то упрощать изображение искать второстепенные детали выводить только видимое то есть делать полноценный 2.5д движок.(что в рамках задачи в явно избыточно )
Попробуй кстати загрузить реально сложный эскиз в профессиональную "колку дров" (Корел Драв )... и прослезись .... ибо тормоз будет ирреальный и невероятный !
Там даже в оптимизированных примерах встречается ТАКОЕ что просто "ужос летящий на крылья ночи " поминать приходится!
zub писал(а):Alex2013
Хотя давно ясно (мне и это мое ИМХО) что как и отрисовка "скриптами", так и "растровое" "выделение" примитивов - тормозилки неприминимые в реальных задачах. Оптимизировать тут нечего, надо переделывать.
"Отрисовка скриптами" уже по сути не применяется (только при загрузке а при изменении добавлении отдельного элемента через скрипт перерисовывается только один элемент )
>>Вся проблема в том, что замечена очень сильная зависимость от размеров рабочего поля ... Непропорциональная !
ну наконецто замечена)) тебе про нее сразу говорили
Это только при определение границ при перерисовке все "тип топ" . (Ну почти "тип топ" ...
бо "совершенству нет предела" )
Зы
Объяснил ведь ! Сейчас все упирается в две "фишки" очистку фона после создания маски и собственно определение границ
(Если ускорить очистку можно будет оставить ОГ как есть и вызвать один раз после нахождения .
Если ускорить ОГ можно примять ее всегда и адресно чистить только рект фигуры при каждой итерации поиска )...
Зы Зы
Кстати обнаружил еще одну "быструю функцию" IndexByte ...
По идее ускорения чистка с ней должна выглядеть примерно так :
Код: Выделить всё
...
Type
TLine=Array [0..sizeOf(Longint)] of byte;
Const
C_B=$F2;
C_C=$F2F2F2;
...
Var
B:TBitmap;
LineSize,Y1,X1:longint;
PLine,ELine:^TLine;
BP:Byte;
PB:^Byte;
...
LineSize:=B.RawImage.Description.BytesPerLine;
...
// Создаю эталон для сравнеия ("Чистый вакуум")
Getmem(ELine,LineSize);FillChar(ELine^,LineSize,C_B);
...
PB:=b.RawImage.Data;
Y1:=IndexByte(PB^,b.RawImage.DataSize,$FF);
If Y1<>-1 then begin
Y1:=(Y1 div LineSize);
Try
b.BeginUpdate;
for Y1:=Y1 to b.Height-1 do
begin
PLine :=b.ScanLine[Y1];
If CompareByte(PLine^,ELine^, LineSize)<>0 then
FillByte(PLine^, LineSize,C_B)
else
if IndexByte(PLine^,(b.Height-Y1)* LineSize,$FF)=-1 then break;
end;
finally
b.EndUpdate;
end
end;
...
По идее код должен быстро вытирать белый контур на темном фоне Но "опять двойка" ...
уже на стадии Y1:=(Y1 div LineSize); лезет какая -то чушь ...
