Быстрая отрисовка графики.

[Haf]

Всем привет! Наконец-таки зарегистрировался на этом форуме:) А то все посещал в качестве тени...
Собственно, к делу. Уже давненько не могу узнать, каким образом осуществляется(как реализовывается, неужели это секрет?!) быстрая отрисовка той или иной графической задачи- к примеру, обычная спрайтовая анимация, возьмем эдак 32битную картинку(серию картинок) 1280х1024. Взять, к примеру, OpenGL! В нем, такая анимация летать будет, да что там одна- сделать много кубиков, приделать к каждому такое дело и все равно- ни каких тебе тормозов и прочего. А вот видновс- в котором даже одна простая череда таких изображений уже вызовет фликеринг(если кривые руки:) ), да даже если не это, то все равно заметно, что приложению становится "тяжело". Возникает вопрос, сам собой, как достигается такая скорость? Ответ, безусловно, кроется где-то очень близко с 'прямым доступом к видеопамяти и к устройству, т.е видеокарте', как я думаю. Но все же? Как опенЖЛ добирается туда? Как бы не смешон был вопрос... Да, опыт общения с опенжл есть. Хочется также попробывать уйти от всяких апи-функции в использовании графики, заменяющих тормознутые функции стандартного модуля Graph. А от апи-функции к опенжл/дайректХ итд? Да, эти библиотеки придуманы для того, чтобы не изобретать велосипед, это понятно. Но ведь интересно же попытаться самому нечто очень отдаленно похожее?
Знаю, также, что все можно реализовать через дорогой и любимый ассемблер (только вот системы уже не 16разрядные, и вся информация, которую я находил- 'просроченная') - еще одна такая вот моя зацепка.
Бывает просто сходишь с ума, когда в твоем приложений пара-тройка анимаций заметно сокращают и память, и быстродействие, в то время как весь рабочий стол, все открытые окна(с их кучей отдельных элементов, требующих отдельной прорисовки) рисуются незаметно для глаза!
В общем, кто понял, что я хотел сказать- отзовитесь, кто не понял или чуть-чуть понял- пишите всё, что поможет разобраться.
Ах, да, чуть не забыл. Среда - Фри паскаль 2.4.0.
Моя Оська- Windows XP SP3, Видюха- nvidia GeForce 9600.

[Odyssey]

Из-за обилия размышлений не вполне понятно, чего вы хотите.

Если хотите показывать растровую анимацию высокого разрешения без тормозов -- нужно использовать соответствующие инструменты (библиотеки, API и т.д.). Тот же OpenGL, SDL (кроссплатформенные), Direct3D (Windows).

Если хотите узнать как устроен OpenGL -- можно найти свободную реализацию, например Mesa 3D и посмотреть её исходники.

Если хотите убрать тормоза в конкретном своём приложении -- лучше уточнить на чём оно написано, с использованием каких API и библиотек (FreePascal + Graph, FreePascal + WinAPI, FreePascal + LCL + TForm.Canvas и т.п.), приложить код. Тогда, возможно, найдётся кто-то, кто сможет вам помочь.

[debi12345]

Рисовать без 3D-ускорения быстре,чем через API операционки и так, чтобы не забирать на себя процессор (с отдачей "тиков",
а не как в ДОСе - монопольно) - врядли получится.
Поэтому используйте GUI-библиотеки на базе FPC - LCL(Lazarus), MSEgui, FpGUI, KOL и т .д. - они как раз вызывают API-рисование.

Да и для 3D/медиа-контента лучше всего использовать спец-API - DirectX, OpenGL, CUDA,.. В принципе, из FPC без проблем
вызываются C-функции, представленные в этих графических DLL.

[Haf]

Хм... Размышлений действительно много. Тогда по порядку. Может быть кто знает, каким образом все эти 3д библиотеки обращаются к видеопамяти, и возможно ли так же, напрямую, использовать их метод ( вывести обычную картинку). К примеру, раньше достаточно было обратится к 'массиву' видеопамяти, записать по ее адресу в этот массив что нужно и все. (скажем так.). Но это так,к примеру о простоте, как работают жк монитор и современные видюхи, я вроде понимаю:)

Добавлено спустя 5 минут 42 секунды:
Да, понимаю, что все таки вопрос не очень простой, наверное быстро не объяснишь. Но все же, очень интересно.

[FedeX]

>Может быть кто знает, каким образом все эти 3д библиотеки обращаются к видеопамяти
Через специальные драйвера, для каждой модели видеокарты - свои. И тут дела не в алгоритмах, никакой ассемблер тут не поможет - все самые ресурсоёмкие расчёты происходят в видеокарте.

>и возможно ли так же, напрямую, использовать их метод ( вывести обычную картинку).
Под WinNT - только писать свой драйвер, что ввиду разнообразия железа не являеться целесообразным. Именно для этого и создавались такие вещи как OpenGL и DirectX - чтобы унифицировать АПИ.

[debi12345]

Непонятно, зачет писать напрямую в видеопамять, если современные видеокарты аппаратно отрисовывают все возможные примитивы - дуги, полигоны и .т.п. И 2-мерные, и 3-мерные.
Насчет картинок - не все карты, но тут вступает в дело графический движок операционки - двойная буферизация, наложения и мапипуляции с размерами ( опять-таки с аппаратной поддержкой), ...
Почему бы вектрную графику не рисовать этими примитивами ? Один фиг объекты реальноо мира описываются не растрами, а примитивами
А вслучае картинок - конвертить в / создавать битмап (в памяти) и скармиливать его в API отрисовки битмапов...

Добавлено спустя 1 минуту 43 секунды:
Есть еще нюансы оптимизации - например, рисовать след от мыши слудует только мелкими отрезками, а не каждый пиксел индивиидуально.

[Haf]

Ага, вот теперь уже яснее, спасибо! Да, я знаю, что все такие библиотеки тем и хороши, что сами отвечают за аппаратную поддержку. Писать заново такой 'мега-драйвер', включая особенности хотя-бы популярных видеокарт- задача не простая...
Тогда вот такой еще вопрос. Я решил попробывать свои силы, да и в качестве спортивного интереса:)- написать свою 'систему меню'(окна, кнопки, скролл-бары итд). Все получилось написать и даже заставить работать без глюков... И даже использовать в небольшой игре. Но минус в том(такой, смешной минус.. ), что все это основанно на любимых вин-апи функциях(вывод графики, события клавиатуры и мыши). Абсурд, правда? В оконной системе писать оконную систему... (не хочется в информации о игре говорить, что все реализовано на вин-апи, ведь тогда весь шик и блеск собственной системы меню исчезает.. )
Но повторюсь, это ради спортивного интереса!
Вопрос такой- куда можно убежать с этих апи?
Вариант опнЖЛ- понятно, но не интересно...
Может стоит сперва понять, что происходит при отрисовке самой обычной кнопки, или маленького окошка в винде- кнопка создана, взаимосвязи с формой и все прочее просчитано, осталось одно- нарисовать. Куда обращается с этим вопросом оконная система винды? (кому письма отсылает? Не своему Биллу же ).

[debi12345]

Вариант опнЖЛ- понятно, но не интересно...

Это почему же ?
Нужно о-о-очень постраться сейчас найти карту+драйвер без поддержки OpenGL/DirectX
Зато получаем в одном флаконе 1) высокоуровневое АПИ (рисование объектами и примитивами)
и 2) полноценное аппаратное ускорение.

[FedeX]

>Вариант опнЖЛ- понятно, но не интересно...
согласен с debi12345. Смешно, но до сих пор не создано не одной вменяемой GUI библиотеки для OpenGL и Free Pascal(/Delphi) жедательно с ООП интерфейсом и (в мечтах) гибкостью вроде Swing для Явы.. А это реально нужная штука. Велосипедов же разных и так хватает.

>Может стоит сперва понять, что происходит при отрисовке самой обычной кнопки
исходники Винды ведь утекали неоднократно, можно и посмотреть)) даже у меня где-то валялись) хотя смысла в этом не вижу - всё-равно всё что ниже WinAPI или OpenGL (или другой библиотеки) - это будет драйвер. В случае с например directx драйвер должен реализовывать определённый интерфейс, и теоретически можно обращаться к этому интерфейсу напрямую.. Но зачем - такое приложение будет работать только под Windows.

[Haf]

Ммм... Значит все таки секрет:) Но все же ясно, что примерно там(при отрисовке кнопок итд) происходит...
По поводу опнЖЛ- да, в этом то и вся петрушка заключается, которая навела меня на все эти 'размышления'... Какая у нее скорость и какая у апишек.
Получается, тот же самый Лазарь, к примеру, для создания элементов меню просто использует для каждой ОС ее библиотеки? Т.е не создает велосипед заново(кнопки и все прочее)?

Добавлено спустя 1 минуту 43 секунды:
По поводу исходников винды- вот это уже интереснее... Надо будет поискать!!!!!

[Odyssey]

Получается, тот же самый Лазарь, к примеру, для создания элементов меню просто использует для каждой ОС ее библиотеки? Т.е не создает велосипед заново(кнопки и все прочее)?

Точно, только если точнее не Лазарь а LCL. Лазарь - это IDE (редактор кода, палитра компонентов и т.д.), а LCL - библиотека, отвечающая за кнопки.

А вот MSEgui и fpGUI сами рисуют все кнопки, используя из API ОС (WinAPI под Windows и xlib API под Linux) только наиболее низкоуровневые функции. Кстати из графических библиотек, написанных на C++ Qt и GTK делают также, и у них тоже открытые исходники.

По поводу исходников винды- вот это уже интереснее... Надо будет поискать!!!!!

Стоит ли тратить на них время, если есть исходники Qt?

[FedeX]

>Стоит ли тратить на них время, если есть исходники Qt?
даю 99%, что Qt и прочие библиотеки подобного рода используют в конечном счёте простой BitBlt.
А вот виндовые нативные контролы (возможно ошибаюсь но где-то слышал) используют некоторое доболнительное аппаратное ускорение (помимо того что BitBlt и сама может быть аппаратно ускорена если железо позволяет).

>По поводу опнЖЛ- да, в этом то и вся петрушка заключается, которая навела меня на все эти 'размышления'... Какая у нее скорость и какая у апишек.
c OpenGL можно рисовать быстрее хотябы потому что она может кешировать текстуры в видеопамяти, что в сотни раз ускоряет вывод спрайтов..

[Иван Шихалев]

Что касается Qt — последние версии вполне используют OpenGL, по крайней мере, под Linux. Правда, собранные без этого, со своим алгоритмом растеризации — работают быстрее на основных задачах.

[debi12345]

но до сих пор не создано не одной вменяемой GUI библиотеки для OpenGL и Free Pascal(/Delphi) жедательно с ООП интерфейсом и (в мечтах) гибкостью вроде Swing для Явы.. А это реально нужная штука. Велосипедов же разных и так хватает.

Ну, здесь нужны энтузиасты - написать OpenGL-варианты виджетов в MSEgui,FpGUI, да и для LCL это будет всего лишь еще один варианты нижележащего виджетсета.

[FedeX]

>написать OpenGL-варианты виджетов в MSEgui,FpGUI, да и для LCL это будет всего лишь еще один варианты нижележащего виджетсета.
тут гораздо больше простора для оптимизаций + гораздо легче добавить различные еффекты - всё таки век унылых серых прямоугольных кнопок с примитивной анимацией потихоньку уходит в прошлое