Как ускорить прорисовку векторной графики ?

[zub]

Векторная графика проецируется на обычный битмап, причем желательно с межпиксельным сглаживанием.

А дальше всё состоит из байтов и битов. ага.
О том что надо изначально хотябы один раз "спроецировать" нашу векторную графику не забыл? в дальнейшем "перепроицировать" при изменениях? и делать это быстро. Это способ сэкономить на повторном выводе изображения - да его нужно использовать для "восстановления" изображения, но быстро нарисовать кучу примитивов это не поможет

Стандартный TCanvas на визуальных контролах постоянно дергает блокировку контекста GUI, провоцирует перерисовку и многие другие гадости. А на невизуальных все происходит гораздо быстрее.

Какую блокировку-перерисовку? Перерисовывается когда надо, блокируется когда надо то что надо. Что за глупости?

А на невизуальных все происходит гораздо быстрее.

Быстрее происходит на аппаратно ускореных контекстах. визуальный-невизуальный-экранный-неэкранный без разницы, если нет аппаратного ускорения - проиграет обычному канвасу визуального контрола (аппаратному GDI контексту) в разы

Пусть название вас не смущает, это уже давно не простой Bitmap.

А какой? это организованый средствами CPU растр, пусть и сглаженный и градиентный... но ТОРМОЗНОЙ. ЕМНИП там были попытки подключить OpenGL - хз чем они кончились, но с глем оно называлось по другому

Это значит, что можно создавать "сцену" из векторных объектов (как в Corel)

Наличие соответствующих примитивов в библиотеке и "манипулировать как в Corel" - две большие разницы не находишь? Довести fpvectorial до состояния вменяемого векторного редактора... давай прикинем что для этого понадобится дописать?

[serbod]

Я вижу, вы в теме разбираетесь лучше меня, но вам интереснее просто спорить. Лучше помогите человеку выбрать оптимальное решение для его задачи.

[zub]

>>но вам интереснее просто спорить. Лучше помогите человеку выбрать оптимальное решение для его задачи.
Я какраз пытаюсь помочь и в этом и в других "векторных" топиках ТС`а, но он никого не слушает - варится в собственной каше

[Alex2013]

Я какраз пытаюсь помочь и в этом и в других "векторных" топиках ТС`а, но он никого не слушает - варится в собственной каше

Просто вы несколько переоцениваете мои возможности и часто не вполне понимаете цели и задачи .
(отсюда получается то что выглядит с моей точки зрения как махровый перфекционизм )

Ладно! Еще раз попытаюсь объяснить "что мы делаем и что мы не делаем "(с) рекламный слоган

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

Отсюда идут все его особенности и кажущаяся "каша" ... То есть если скритовый движок реально нужно "вылезать до блеска" и снабдить своей средой разработки то гнаться за глобальной сверх-оптимизаций визуализации смысла нет .

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

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

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

[zub]

>>Но и сама прорисовка тоже место явно узкое .
Чудес не бывает. Если в качестве "рисователя" выбран канвас - рисовать быстрее чем он умеет не получится, но тебе его возможностей имхо заглаза.
Я вообще непонимаю что может тормозить на отрисовке 50 "объектов" поэтому и говорю что нужна система "дебага" отрисовки со статистикой "куда уходит время"

>>На пример я бы не отказался от методик быстрого копирования "теневых страниц" на экран
bitblt (в винде использовать windows.bitblt, в линуксе bitblt из LCLIntf) в помощь - самый быстрый вариант при использовании lcl, но при его использовании нужно соответствующим образом создать внеэкранный контекст.
В зкаде я использую самописный контрол, который имеет 2 режима рисования: 1-полная перерисовка и запоминание картинки в внеэкранный буфер, 2 восстановление картинки на экране из внеэкранного буфера. Причем восстанавливается только область требующая восстановления.
режим 2 работает примерно так: восстанавливается область испорченая в прошлом кадре, поверх изображения рисуется курсор (не использую системный курсор), "подсвечивается" рамкой примитив находящийся под курсором, рисуется копия редактируемого в данный момент примитива (если он есть), испорченая область запоминается для восстановления в следующем кадре
https://youtu.be/IA3V61_GaNY на 0:40 - включение "отладки" GDI-рисовалки и дальше видно "диагональный" крест на области чертежа - это "подсветка" "восстанавливаемой" области. она закрвает мышиный курсор и текстовый примитив когда он находится под курсором. В моменты когда чертеж "ZOOMируется" или "PANится" у меня происходит полная перерисовка контрола, хотя для PANа можно "пририсовывать" только вновь появившуюся на экране область - я не стал так замарачиваться.

>>умного скролинга
Не используй штатный скролбокс, юзай отдельные скролбары и перерисовывай чертеж от их положения. + отбраковка примитивов лежащих за пределами области = умный скролинг

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

кстати, если ты не планируешь использовать зум - вместо метафайла можно использовать битмапы созданые на стороне GDI - для негабаритных объектов должно быть быстрее метафайла.

кстати2, реализация winapi предоставляемая lclными модулями LCLIntf и LCLType кроссплатформенная, вышеописаное у меня работает в win\qt\gtk

[Alex2013]

Вот уже интереснее !

1. Вообще насчет вычисления размеров есть идея из серии "что нам мешает то нам поможет" ...
То есть в сам скрипт добавить не слишком сложный код определяющий минимальные и максимальные координаты при рисовании примитивов .
2. Зум делать планирую .
И еще хочу сделать окошко "миникарты" .

3. "Не используй штатный скролбокс, "
Именно так все и сделано . Скрол сделан за счет сдвига паинтбокса .
Но узкое место в перерисовке приходится рисовать весь контент не важно видимый он или нет ...
Если простые линии можно сравнительно не сложно обрезать математически то как просто обрезать например элипс или полигон ? В прочем есть идея ... если будут ясны размеры можно рисовать спрайт и резать его (или вообще отбрасывать) до склейки в большой коллаж .

4."Я вообще непонимаю что может тормозить на отрисовке 50 "объектов" ..."
Тормозить может и один объект если это например картинка или фоновый градиент солидного размера .
( И вообще современные приложения приходится рассчитывать исходя из разрешений экрана близких к сакраментальному Ultra HD 4K (3840 × 2160) ведь даже я (хронический юзатель дешевого железа ) могу растянуть приложение на два экрана 1980+1280 Х 1080) ...

[alexey38]

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

Вначале делали под DOS на BP 7.0 под компы i386/486. Потом делали под Win95 и выше на Delphi 7/2007 для работы на компах начиная с Pentium II/III. Соответственно ни в первой реализации, ни во второй ни о каком аппаратном ускорении речь не шла, т.к. не было на чем это делать. Работало все довольно быстро, как в досовской (самый быстрый вариант), так и виндовых вариантах.

Виндовый вариант был сделан так. Сложные элементы вначале все были заранее прорисованы в свои отдельные метафайлы (каждый для отдельного элемента). Потом общая картинка выводилась в общий метафайл, уже с учетом скролбара и масштаба, т.е. непопадаемые в видимую область элементы просто не прорисовывались. Потом метафайл отображался в Bitmap, и уже Bitmap отображался на Canvas.

Работало (и работает до сих пор) все очень шустро даже на старых компах (Pentium II/III с самыми примитивными видеокартами). Причем не просто быстро, ни и не было раздражающей поэлементной прорисовки элементов и примитивов.

Также проводили сравнение в быстродействии. Общую картину из метафайла сохраняли в файл emf/wmf, и импортировали в различные профессиональные векторыне редакторы типа Corel Draw и ему подобные. У нас все работало намного быстрее, чем в этих системах, причем довольно существенно.

[Лекс Айрин]

( И вообще современные приложения приходится рассчитывать исходя из разрешений экрана близких к сократительному Ultra HD 4K (3840 × 2160) ведь даже я (хронический юзатель дешевого железа ) могу растянуть приближение на два экрана 1980+1280 Х 1080)

то есть, если даже монитор 640х480, то буфер отображения будет 3840 × 2160?.. OMG не удивительно, что программа тормозит...

[Alex2013]

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

Задача "Чистый просмотр" разумеется почти всегда будет быстрее чем работа в редакторе .
(Там многое можно делать по принципу "нарисовал и забыл" а редактор должен хранить ВСЕ данные в объектной форме уметь двигать и преобразовывать каждый объект отдельно )


Идеальным (и для меня - Увы! - пока недостижимым) примером скорости рисования сложной масштабируемой графики считаю ZUI типа Eagle Mode http://eaglemode.sourceforge.net/ да там почти все растровое но во первых не все, а во вторых при таком количестве данных разницы между векторным и растровым изображением почти нет ...

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

( И вообще современные приложения приходится рассчитывать исходя из разрешений экрана близких к сократительному Ultra HD 4K (3840 × 2160) ведь даже я (хронический юзатель дешевого железа ) могу растянуть приближение на два экрана 1980+1280 Х 1080)

то есть, если даже монитор 640х480, то буфер отображения будет 3840 × 2160?.. OMG не удивительно, что программа тормозит...

Нет разумеется буфер у меня динамический и его размер зависит от размеров окна (точнее размеров рабочей области ).
Но считаю что рассчитывать, что программа всегда будет работать в "тепличных " условиях старого 17" дюймового монитора с разрешением 1024х768 сейчас просто нельзя .
(В разрешении "по умолчанию" программа уже сейчас идет довольно шустро )

[Лекс Айрин]

Alex2013, не... ты ответь.

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

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

а редактор должен хранить ВСЕ данные в объектной форме уметь двигать и преобразовывать каждый объект отдельно

Это не значит, что надо постоянно перерисовывать всю картинку. Есть же методы перерисовки только затронутых объектов (попавших в область отрисовки.) причем, не разница между векторным и растровым изображением на первых этапах минимальна.

[Alex2013]

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

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

Ну мне пока и памяти хватает (Свап в линуксе 0 ) в винде меньше четверти физической памяти ...
А в досе автоматического свапа не было в принципе .

а редактор должен хранить ВСЕ данные в объектной форме уметь двигать и преобразовывать каждый объект отдельно

Это не значит, что надо постоянно перерисовывать всю картинку. Есть же методы перерисовки только затронутых объектов (попавших в область отрисовки.) причем, не разница между векторным и растровым изображением на первых этапах минимальна.

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

[zub]

>>Общую картину из метафайла сохраняли в файл emf/wmf, и импортировали в различные профессиональные векторыне редакторы типа Corel Draw и ему подобные. У нас все работало намного быстрее, чем в этих системах, причем довольно существенно.
Это не совсем честное сравнение emf/wmf - всё хранит в самых элементарных примитивах. соответственно "и ему подобные" имеют большую кучу элементарщины, вы же имеете эту элементащину скомпонованую в "блоки" более высокого уровня - что позволяет например отбросить всё внутренюю элементарщину проверив только видимость "блока". Набор "иерархичных" данных всегда предпочтительнее "одноуровнего"

>>И еще хочу сделать окошко "мникарты" .
Т.е. думай в сторону отображения одних и техже данных в нескольких окнах и уровне детализации - в миникарте (или при соответствующем зуме) для начала буквы в слове можно заменить на квадратики, потом всё строку текста можно заменить простой линией. При наличии зума нормальную скорость без подобных трюков не получить
>>Но узкое место в перерисовке приходится рисовать весь контент не важно видимый он или нет ...
Который раз повторяю - рисовать надо только то что видимо.
>>то как просто обрезать например элипс или полигон ?
Резать ниче ненадо, графическая система без тебя справится с подрезкой. Надо просто не отправлять на отрисовку примитивы которые заведомо не попадают в область отображения

>>Тормозить может и один объект если это например картинка или фоновый градиент солидного размера .
Ну в твоем то тестовом файлике ~50 хренек которые сегодня любой телефон нарисует незаметив

[Alex2013]

Кстати, скроллинг ускорил ... Из совершенно неудобоваримого он стал "умерено терпимым "...
Код прорисовки теперь такой...

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

//705********************************
// Прорисовка списка фигур
//********************************
//********************************
{META2}
procedure TRF1.PaintBox1Paint(Sender: TObject);
var I:Integer;
    Buf_BMP:TBitmap;
    R:Trect;
    MC:TMetafileCanvas;
    MyMetafile: TMetafile;
    Const
      FMD:Boolean=True;
      FADD:Boolean=True;
begin
//Установить текущий  Canvas
   Buf_BMP:=TBitmap.Create;
   Buf_BMP.SetSize(PaintBox1.Width,PaintBox1.Height);
   CurCanvas:=Buf_BMP.Canvas;
   CurCanvas.Pen.Color:= 0;
   CurCanvas.Brush.Color:=  RedColor0;
   CurCanvas.FillRect(rect(0,0,PaintBox1.Width,PaintBox1.Height));
// ! Cliar при больших размерах PaintBox-а работает не всегда....
// Почему кстати совершенно не понятно ... 
Timer1Timer(Sender);//тут  сетку грида  рисует ...
R:=RECT(0,0,PaintBox1.Width-1,PaintBox1.Height-1);
if DrawList<>NIL then
  if DrawList.Count >0 then begin
  If MetaDrawList = Nil Then MetaDrawList:=Tlist.Create ;
  If ShadowDrawList  = Nil Then Begin ShadowDrawList:=TStringlist.Create ;
                                      ShadowDrawList.Text:=DrawList.Text;
                                end;
//Если  в списке бльше одной фигуры ...
if DrawList.Count>0 then
For I:=0 TO DrawList.Count-1 DO
Begin
FADD :=FmD Or  (I > ShadowDrawList.Count-1);
FADD := FADD Or  (I > MetaDrawList.Count-1);
FADD := FADD Or  (ShadowDrawList[I] <> DrawList[I]);

If FADD Then
  begin
  // Инициализирую метафайл ...
   MyMetafile := TMetafile.Create;
   MC:= TMetafileCanvas.CreateWithComment(MyMetafile, Buf_BMP.Canvas.handle,
   'Author', 'Made This');
   CurCanvas:=MC;//Перенаправляю Canvas
     DrawFig(-1,DrawList[i]);
    MC.Free; //! Обязательно очищать MetafileCanvas  преред "клонированием" ...

If FmD then MetaDrawList.Add(MyMetafile) else
               if I<=MetaDrawList.Count-1 then begin
                                       TMetafile(MetaDrawList[i]).Free;
                                       MetaDrawList[i]:=MyMetafile;
                                       end else
                                        if  I=MetaDrawList.Count  then
                                                      MetaDrawList.Add(MyMetafile);

CurCanvas:=Buf_BMP.Canvas;
CurCanvas.Draw(0,0,TMetafile(MetaDrawList[i])); //draw normal
  end else
begin
  CurCanvas:=Buf_BMP.Canvas;
  CurCanvas.Draw(0,0,TMetafile(MetaDrawList[i])); //fast draw
  end
end ;
FMD:=False ;
FADD:=True ;
ShadowDrawList.Text:=DrawList.Text;
Listbox1.Items.Text:=DrawList.Text;
end;
// Копирую буфер на экран
PaintBox1.Canvas.CopyRect(  R , Buf_BMP.Canvas,  R );

CurCanvas:=PaintBox1.Canvas;  // Востанавливаю текущий канвас
Buf_BMP.Free; // Очистка буфера
end;


Сам скроллинг пока туп как пробка но надежен как чугунный утюг !

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

// Скрол Y
procedure TRF1.ScrollBar1Change(Sender: TObject);
begin

PaintBox1.SetBounds(-ScrollBar2.Position,-ScrollBar1.Position
                              ,ScrollBar2.Position+panel2.Width
                              ,ScrollBar1.Position+panel2.Height);
PaintBox1.Refresh;
end;
// Скрол Х
procedure TRF1.ScrollBar2Change(Sender: TObject);
begin

PaintBox1.SetBounds(-ScrollBar2.Position,-ScrollBar1.Position
                           ,ScrollBar2.Position+panel2.Width
                           ,ScrollBar1.Position+panel2.Height);
PaintBox1.Refresh;
end;


[Лекс Айрин]

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

Зря сомневаетесь. Это стандартная оптимизация любого нормального графического (а уж тем более векторного) редактора, оконного менеджера и кучи разных программ. Например, игрового движка. Думаю, не слишком сильно ошибусь, если скажу, что постоянная перерисовка всего контекста и есть основная причина тормозов.

[Alex2013]

>>И еще хочу сделать окошко "миникарты" .
Т.е. думай в сторону отображения одних и техже данных в нескольких окнах и уровне детализации - в миникарте (или при соответствующем зуме) для начала буквы в слове можно заменить на квадратики, потом всё строку текста можно заменить простой линией. При наличии зума нормальную скорость без подобных трюков не получить

Ну саму "мини карту" я просто на масштабируемый Timage выведу .. Фокус проверенный даже в этой программе ( Как думаешь я миниатюры в библиотеке блоков сделал (Благо что у меня основной канвас сменный ! )
Если обновлять "мини карту" не слишком часто думаю проблем не будет совсем ...
А вот основной редактор сделать масштабируемым действительно чуть сложнее (Нужно например не потерять связи с координатами мышки и т.д. ).

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

Ну это проще ... Хотя картинку градиент или что-то еще похожее неплохо все-же бы обрезать заранее .

>>Тормозить может и один объект если это например картинка или фоновый градиент солидного размера .
Ну в твоем то тестовом файлике ~50 хренек которые сегодня любой телефон нарисует незаметив

Сейчас сделал картинку за 100 элементов ... Работает без явных тормозов.... Но дело в том, что уже есть элементы "особого назначения " (а дальше их больше будет ) и они при значительных разрешениях способны "испортить всю малину " да и вообще любое изображение при разрешении Фул-ЭйчДи и выше способно заставить задуматься если не железо компа так программиста уж точно .

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

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

Зря сомневаетесь. Это стандартная оптимизация любого нормального графического (а уж тем более векторного) редактора, оконного менеджера и кучи разных программ. Например, игрового движка. Думаю, не слишком сильно ошибусь, если скажу, что постоянная перерисовка всего контекста и есть основная причина тормозов.

Верно, но как прорисовать одну вертикальную или горизонтальную полосу при скроллнге ?
"2.5D Редндер" писать все-же для задачи где будет максимум 500 элементов на одно изображение (имхо) явно избыточно .Вывод: нужно что-то простое, почти грубое.... но что бы работало надежно и просто . Есть идея сделать "прогрессивное" рисование деталей. То есть сохранить растровые "спрайты" с низкой детализацией и выводить их быстро, а потом в фоновом режиме незаметно строить все детально !