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

[zub]

Не трать время зря - это ерунда.
Самые быстрые способы копирования:
GDI - создать совместимый контекст, создать совместимый битмап, асоциировать битмап с контекстом, скопировать bitblt`ом с контекста канваса на совместимый контекст. Восстановить изображение обратным копированием. при этом сохраненная копия остается "внутри" видеосистемы и при нормальном драйвере данная операция выполняется максимально быстро.
OpenGL - создать нужное количество текстур небольшого размера 64х64 или 128х128 чтоб "перекрыть" всю сохраняемую область. скопировать содержимое из активного буфера (с изображением) в текстуры с помощъю glCopyTexSubImage2D. Восстановить изображение рисованием квадов с соответствующими текстурами в ортогональной проекции тексель в пиксель. Это будет работать на самых древних компах, можно еще юзать для сохранения auxbufer, accumbufer, "современные" расширения - но это уже может гдето неработать. Также можно создать одну большую текстуру (в весь размер выводимой области) вместо кучи мелких - тоже будет работать невезде.

[Лекс Айрин]

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

Вообще-то, данный буфер должен создаваться в видеопамяти. И с частотой обновления экрана он переносится на матрицу монитора. Все остальное это высокоуровневые функции менеджера окон. причем, многоуровневые:
1) заливка изменений в, условно, буфер монитора.
2)заливка изменений (или сборка) буфера окна
3) отрисовка компонент.
Ну и куча промежуточных шагов. Так вот. Ты хочешь состыковать мало того что данные разных уровней, так еще и разных подсистем. Не стоит забывать, что для аппаратного отображения картина взаимодействия немного иная. Ну и не факт, что данные находятся в совместимых форматах.

Я вычитал, что якобы OGL юзает ДМА мимо процессора, а это значит, что есть шанс, что выйдет быстрее.

Не стоит забывать, что:
1) южный мост (контроллер памяти) не работает просто так -- ему все равно надо указать что и куда перемещать.
2) ЮМ на новых системах часть проца.

[olegy123]

Я вычитал, что якобы OGL юзает ДМА мимо процессора, а это значит, что есть шанс, что выйдет быстрее.

Это уже разработчики драйвера для видеокарты решают когда задействовать DMA.
- только представь что помимо понимания OGL тебе еще нужно разбиратся в работе железа, режимов работы конкретного чипа, какая память используется, какие тиминги..

Добавлено спустя 2 часа 38 секунд:

Вопрос: есть-ли простой "патентованный метод " ускорения отрисовки векторной графики ?

Его нет, как нет общего принципа рисования векторной графики. Вектора - это математический выражения. Линии,круги, элипсы - из геометрии.
В растовой грфике, как пример, при рисовании линии вы используете функцию которая по заданным координатам вам дает массив точек в растре через которые эта линии проходит. И вы их самостоятельно закрашиваете.
В канве 2D рисуется через такие функции. А сама GUI - это более расширенная библиотека, в которой есть уже понимание битмапа, линии, полигон, заливка и прочее..

Как рисуют на канве, на 3D ускорителях так не рисуют.
В 3D ускорителях там иной подход рисования. Более примитивен и упрощен до понимания треуголников текстур и шейдеров.

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

Мой "редактор форм и страниц" растет и ширится ... и вместе с ним растут объемы и сложность графики .

У меня вопрос, а как будут отображаться CSS? JS?
Почему бы не использовать "Chromium Embedded Framework" -? Он умеет "Rendering Web content “off-screen” in applications that have their own custom drawing frameworks."
сейчас некоторые(Опера) бросили делать свои движки для отображения вэб-контента, только из-за того что это сложная задача: помимо того что стандарт постоянно расширяется, нужно думать о том как все это заставить работать на различных устройств. С этим злом активно работают сотрудники из Гугла.

[zub]

>>Его нет, как нет общего принципа рисования векторной графики.
Куда он делся то)) Общий принцип всех лентяев подходящий для всего:
Делай только то что необходимо в минимальном необходимом объеме = рисуй только то что видимо, в минимально подходящей детализации

[serbod]

Не трать время зря - это ерунда.

Время на то и дается, чтобы его тратить, а не копить. Пусть попробует разные способы. Есть же еще framebuffer, DirectDraw, GDI+.

[Лекс Айрин]

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

На самом деле все ровно наоборот. Стандарт расширяется из-за того, что надо выпускать новые версии. Основная проблема в том, что развитие идет вширь, а не вглубь. На данном этапе, по хорошему, надо перетрясти код и убрать структурные баги (и, конечно, обычные), а потом уже расширять стандарты. А то взлом новых суперзащищенных программ происходит чуть ли не быстрее чем они пишутся.

[Alex2013]

Я вычитал, что якобы OGL юзает ДМА мимо процессора, а это значит, что есть шанс, что выйдет быстрее.

Это уже разработчики драйвера для видеокарты решают когда задействовать DMA.
- только представь что помимо понимания OGL тебе еще нужно разбиратся в работе железа, режимов работы конкретного чипа, какая память используется, какие тиминги..

Угу. очередной сезон "Замри и гори"( "Halt and Catch Fire")...

Добавлено спустя 2 часа 38 секунд:

Вопрос: есть-ли простой "патентованный метод " ускорения отрисовки векторной графики ?

Его нет, как нет общего принципа рисования векторной графики. Вектора - это математический выражения. Линии,круги, элипсы - из геометрии.
В растовой грфике, как пример, при рисовании линии вы используете функцию которая по заданным координатам вам дает массив точек в растре через которые эта линии проходит. И вы их самостоятельно закрашиваете.
В канве 2D рисуется через такие функции. А сама GUI - это более расширенная библиотека, в которой есть уже понимание битмапа, линии, полигон, заливка и прочее..

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

Как рисуют на канве, на 3D ускорителях так не рисуют.
В 3D ускорителях там иной подход рисования. Более примитивен и упрощен до понимания треуголников текстур и шейдеров.

Так я и не собираюсь пока лезть в 3D ...

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

Мой "редактор форм и страниц" растет и ширится ... и вместе с ним растут объемы и сложность графики .

У меня вопрос, а как будут отображаться CSS? JS?
Почему бы не использовать "Chromium Embedded Framework" -? Он умеет "Rendering Web content “off-screen” in applications that have their own custom drawing frameworks."
сейчас некоторые(Опера) бросили делать свои движки для отображения вэб-контента, только из-за того что это сложная задача: помимо того что стандарт постоянно расширяется, нужно думать о том как все это заставить работать на различных устройств. С этим злом активно работают сотрудники из Гугла.

1 С CSS пока не. все отдано на откуп фоновой страницы... По сути думаю обойтись набором чуть настраиваемых стилей-фонов.

2 JS? А что с ними может быть не так ? У меня уже используется библиотека векторной графики Raphael.js (кстати моя поделка наверное единственный оффлайн редактор который пусть пока далеко не полностью но реально поддерживает Raphael-графику ) JS это же просто такой же код как и любой другой так что я планирую целый раздел "Набор JS" куда будет добавлять почти любый "красивости" сделанные на JS ... Кстати можете сами попробовать сделать свои элементы по аналогии с существующими (вроде там все прозрачно до тупости)...

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

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

[Лекс Айрин]

И иногда можно заставить систему "пользоваться лифтом" или вообще нагло проигнорировать ее навязчивый сервис .

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

[Alex2013]

Все верно но пример того же Raphael.js говорит, что можно полностью оставаясь в рамках системных ограничений "обойти систему на повороте" . (Там как я понял сделали полностью собственные механизмы рисования примитивов на создаваемом обычным путем битмапе ... Результат не меньшая, а БОЛЬШАЯ совместимость с разными браузерами и ОС при вполне приличной скорости прорисовки, вполне достаточной даже для анимации )

[Лекс Айрин]

[

...можно оставаясь полностью в рамках системных ограничений "обойти систему на повороте" .

практика показывает, что шанс влететь в отбойник достаточно велик((

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

[Alex2013]

Вот именно! Многие движения "тонкой души ОС" для конкретной задачи просто не нужны !
И можно ПОЛНОСТЬЮ оставаясь на уровне прикладной программы взять на себя часть работы обычно проделываемой ОС (или стандартной библиотекой типа LCL) .
(Разумеется, эта уловка работает если код программы гарантированно сделает необходимые действия быстрее и не менее надежно чем это делается стандартным способом .... + нужна уверенность в том что туд затраченный на оптимизацию целесообразен в принципе )

[Лекс Айрин]

Вот именно! Многие движения "тонкой души ОС" для конкретной задачи просто не нужны !

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

Это все равно что из стенки вынимать кирпичи... раз дом стоит, то они как бы не нужны, но проедет трамвай и на 5-10 раз дом рухнет. И не стоит забывать, что недокументированные возможности могут быть изменены в любой момент, а это -10% к совместимости. Пролистай код Lazarus и посмотри сколько там закомментированных и устаревших функций...

И можно ПОЛНОСТЬЮ оставаясь на уровне прикладной программы взять на себя часть работы обычно проделываемой ОС (или стандартной библиотекой типа LCL) .

WinAPI и LCL(библиотека компонент компилятора) это разные уровни. И сравнивать их некорректно. Понятное дело, что надстройка проиграет в производительности. Её задача ускорить и облегчить написание программы за счет вставки стандартного кода. И, конечно, там много лишнего (и "лишнего" тоже ), а то и мертвого для данной программы кода. Это реальность данная нам свыше.

Разумеется, эта уловка работает если код программы гарантированно сделает необходимые действия быстрее

точнее, гарантированно сделает ВСЕ необходимые действия... а вот уверенность в этом есть далеко не всегда.

[Alex2013]

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

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

Другое дело, что чаще всего такой "финт ушами" будет немереной глупостью и банальным "изобретением велосипеда "...
Но бывают случаи когда подобная самодеятельность вполне оправдана.

[Лекс Айрин]

Уверенность в том что-то код сделает все как надо как раз почти всегда полно

вот только вопросов как что-то делается еще больше... знаково, однако...

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

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

[zub]

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

Топор тормоза у тебя в руках. Ты можешь сказать что конкретно тормозит? Повторяю, объем отрисовки который есть у тебя - рисовался не напрягаясь 20 лет назад.
У тебя какаято каша в голове - передать в опенгл битмап, тогда заработает дма... Жесть((
Сделай отладочные замеры времени у себя, сделай экспортимпорт любого общепринятого формата - чтоб глядеть как подобный объем отрисовки ведет себя в нормальных программах и чтоб иметь возможность загрузить к себе чтонить побольше для тестов.
Тогда появится конкретика, а не флейм с фантазиями

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

Время на то и дается, чтобы его тратить, а не копить. Пусть попробует разные способы. Есть же еще framebuffer, DirectDraw, GDI+.

Способы конечно надо пробовать, но откровенный бред лучше сразу отсеять, на то и общение на форуме