O>>Ох. НЕТ. Вам уже писали, и ссылки приводили — что device-dependent битмап — это видеопамять видюхи, UpdateLayeredWindow — ускоряеся драйвером, функции которые XPDM драйвером должны для этого имплементиться — список выше. Но вы почему-то логике не внемлете, зациклившись по кругу.
CS>Ох ё-моё еще один фантазер.
CS>device-dependent bitmap (DDB) это т.н. compatible bitmap.
CS>Сompatible bitmap это bitmap совместимая по layout и color organization c каким-нибудь device. ЭТО НЕ ЕСТЬ bitmap в видео памяти. У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти. Когда-то в древности такое было на каком-нибудь Z80, но уже давно как нет.
Открой девайс манагер, свойства видюхи, вкладка Resources, посмотри Memory ranges, обрати внимание на порядок размера цифр в старших адресах — это "окна" в физической памяти для доступа к памяти видеокарты таким вот образом. А еще обрати внимание то, что старый добрый A0000-BFFFF все еще там, если эти цифры тебе ни о чем не говорят — то с тобой вообще не о чем разговаривать.

CS>И вот тебе цитата из Феня нашего Юаня:
А тебе вот цитата разраба из нвидии https://www.quora.com/Can-a-CPU-access-the-contents-of-VRAM-or-can-it-only-be-accessed-by-GPU

ЗЫ Это не только в РС так. Я както программировал на распберри под DirectFB v1.0.2 идущий с распбианом, так вот создавая primary DFSCL_FULLSCREEN поверхность и вызывая на нее Lock — получаешь на руки _юзермодный_ поинтер на _фреймбуфер_, запись в который отображается непосредственно на экране, даже если никогда не вызывать Unlock. Работа с этим буфером кстати заметно медленнее работы с обычной памятью — тестовый бенч на memcpy дает в разы худший перфоманс чем на памяти выделенной malloc'ом.

ЗЗЫ Теперь я понимаю как в мс делают "новые" фичи. Просто забывают как работают старые и делают новые велосипеды, которые ездят ровно так же, просто раскрашенные в другой цвет.