BitBlt на контекст DC и его альтернатива

[notHaker]

Здраствуйте уважаемые Делфисты! Не могли бы вы подсказать более быстрый метод Блиттинга на DC контрола. ТК пишу ассемблерную библу графики, но всё сошлось на тормозах ГДИ. гугл = 0! В душе понимаю, что скорее всего ДЦ закрыт и кроме BitBlt ничего нету, но возможна ли альтернатива? поделитесь опытом! заранее спасибо!!!

[BOBAH13]

Сообщение от notHaker

Здраствуйте уважаемые Делфисты! Не могли бы вы подсказать более быстрый метод Блиттинга на DC контрола. ТК пишу ассемблерную библу графики, но всё сошлось на тормозах ГДИ. гугл = 0! В душе понимаю, что скорее всего ДЦ закрыт и кроме BitBlt ничего нету, но возможна ли альтернатива? поделитесь опытом! заранее спасибо

Так давайте определимся, вы создаете графическую библиотеку для графики или для GUI под Windows ? Если второе, то наоборот, надо выполнять поддержку HDC только так, а в чем собственно загвозка то ? В чем выявляются "тормоза" ?

[0nni]

SetDIBitsToDevice() не намного, но быстрее. Хотя не знаю чем вас скорость не устроила. Просто при копировании битмапа (1024x768) на экран, у меня доходило до 300fps, хотя, различия в глубине цвета думаю могут повлиять.
Если нужен действительно быстрый вывод - то воспользуйся прямым доступом к видоепамяти через DirectDraw. На васме можешь примеры найти.

[notHaker]

Да, нужно организовать поддержку GDI. НО. DirectDraw имеет посредственную поддержку GDI, так что функции AlphaBlend(и не только) "выносят" поверхность за пределы формы, а BitBlt - это дрянной побайтовый рендеринг.

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

В StretchDIBits (копирование из собственного буфера памяти в экран) если картинка не требует масштабирования и перекодировки глубины цвета то копирование аппаратно ускоряется даже на ооочень стареньких видеокартах и никакой разницы по скорости с ДХ не заметно. Если же глубину цвета нужно менять, то есно StretchDIBits работает намного медленнее чем при просто копировании, но в ДХ я вообще не нашёл подобной возможности, так что сравнивать скорость StretchDIBits можно только с собственным (или найденным в сети) алгоритмом перекодировки глубины цвета
Ещё интересные грабли - независимо от того StretchDIBits, ДХ или что-то ещё, аппаратный ускоритель подхватывает только выровненные как по положению, так и по длине строк блоки памяти, поэтому если просто копировать произвольный по размерам прямоугольник куда попало, то скорость копирования будет сильно различной (то программной, то аппаратной)

Юзал от сель. Господа профи... ваши соображения по этому поводу. .

Там у господина bo0h была примерно таже проблема, что и у меня. Лучшего я не нагуглил . Посоветуйте, поделитесь опытом, а нито я уже вспотел блин! Диплом стоит... заранее спасибо.

Ну неужели никому дела до этого нет...

[notHaker]

И исчо... "выровненные как по положению, так и по длине строк блоки памяти" - это как..? Я вабще ничего не понимаю... тугодум *ля...

[BOBAH13]

Ну или хотя бы поскажите что сделать шоб при SetLayeredWindowAttributes поверхность DDraw не "слетала".

Без понятия что это значит точно, но как я понимаю, и как надо делать и почему?!
1. Вам Windows не даст прямого доступа за просто так (имеется ввиду без драйверов и т.п.. в ring0) к видеопамяти что это может значит?
2. Видео память - а именно быстрый доступ дает вам такие вещи как DirectX, OpenGl и др.
3. Если уж беретесь за отрисовку через подобные либы то опять таки свести все к HDC
4. Имеяя HDC использовать нужные Вам Windows API - может вы не заметили, но обычно окна HWND и контексты отрисовки HDC во всех API основных, это все таки правило.
Думаю сделаите выводы. А пытатся на прямую через DirectX рисовать и взаимодействовать сразу с API такие как Layered Windows тем более, не даст ничего хорошо. Самый оптимальный вариант, отрисовка в буфере (в памяти на HBITMAP + HDC + Scan0, вообщем DIB секция) и потом с использованием соотвествующего HDC вызывать API связанные с Layered Windows.

p.s. а можете озвучить тему дипломного проекта ? А то просто мне тоже через пару лет писать

[notHaker]

Сообщение от BOBAH13

Без понятия что это значит точно, но как я понимаю, и как надо делать и почему?!
1. Вам Windows не даст прямого доступа за просто так (имеется ввиду без драйверов и т.п.. в ring0) к видеопамяти что это может значит?
2. Видео память - а именно быстрый доступ дает вам такие вещи как DirectX, OpenGl и др.
3. Если уж беретесь за отрисовку через подобные либы то опять таки свести все к HDC
4. Имеяя HDC использовать нужные Вам Windows API - может вы не заметили, но обычно окна HWND и контексты отрисовки HDC во всех API основных, это все таки правило.
Думаю сделаите выводы. А пытатся на прямую через DirectX рисовать и взаимодействовать сразу с API такие как Layered Windows тем более, не даст ничего хорошо. Самый оптимальный вариант, отрисовка в буфере (в памяти на HBITMAP + HDC + Scan0, вообщем DIB секция) и потом с использованием соотвествующего HDC вызывать API связанные с Layered Windows.

p.s. а можете озвучить тему дипломного проекта ? А то просто мне тоже через пару лет писать

Диплом : (если коротко) Написать движок оконной графики (те свой GDI(по началу я даже испугался ), НО доверить винде лишь окна, и дочерние тоже). Как мне объяснили "похорошему", приветствуется быстрота, качество и, главное, оригинальность работы. Исчо объяснили, что копирование будет жестоко наказано!!

вобщем вернулся туда, от куда начинал... ну серавно спасибо.

И всё таки как насчёт вот этого :

Ещё интересные грабли - независимо от того StretchDIBits, ДХ или что-то ещё, аппаратный ускоритель подхватывает только выровненные как по положению, так и по длине строк блоки памяти, поэтому если просто копировать произвольный по размерам прямоугольник куда попало, то скорость копирования будет сильно различной (то программной, то аппаратной)

как это понимать?? что за выравнивание такое??

[notHaker]

ну господа модеры... откликнитесь пожалуйста...
эх... неужели тема быстрого блитинга никому не интересна?