> Разговор начался в самом самом начале о количестве буферов
> перед попаданием из MemDC в окно.


Во front buf адаптера

> [119] oxffff ©   (24.03.08 20:54)


> А чем ты рисуешь?

я рисую контекстом устройства )) для того он и создан.

> А то что он необычный по провалу при вызове GetObject

ну используется для каких то системных нужд.. мало ли.

> Разговор начался в самом самом начале о количестве буферов
> перед попаданием из MemDC в окно.

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

> Системе нет смысла заниматься кэшированием битмапов и других
> растровых операций на прикладом уровне

уточню, GDI операции могут кэшироваться, для этого даже есть спец. функции, но в предыдущем посте речь о кэшировании уже отрисованой картинки, а не пакетном выполнении GDI операций.

> я рисую контекстом устройства )) для того он и создан.


Ты рисуешь как раз на этом битмапе. Действительно получается что битмап общий с clip областями. Фактически может представлять собой буфер в RAM или VIDEO памяти или являтся front буфером.


> OWNDC создан просто для повышения быстродействия, кэширования
> никто и не обещал. каким образом достигается


Это понятно стало из примеров. :)

> Eraser ©   (24.03.08 21:14) [122]


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

> [123] oxffff ©   (24.03.08 21:19)


> Действительно получается что битмап общий с clip областями.
> Фактически может представлять собой буфер в RAM или VIDEO
> памяти или являтся front буфером.

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

oxffff ©   (24.03.08 20:54) [119]


> То что буфер есть можно узнать по
> HBM := GetCurrentObject(DC, OBJ_BITMAP).


Это не буфер нифига


> А то что он необычный по провалу при вызове GetObject


Вот потому и проваливается, что не буфер. Купи уже книжку Фэня Юаня и прочитай.

oxffff ©   (24.03.08 21:19) [123]


> Ты рисуешь как раз на этом битмапе.


Фига с два. Ты отдаешь команды рисования драйверу. А он уже определяет, где и как ему рисовать, то ли вызывать средства GDI (точнее, GRE - Graphics Rendering Engine - ядерная часть GDI), то ли вызывать аппаратные средства видеоадаптера.

Иначе получается, что аппаратные 3D ускорители занимаются анализом изображения нарисованного на битмапе, что есть ерунда.

Купи уже книжку Фэня Юаня.

А может, термин "двойной буфер" предполагает то, что 1-й буфер - это контекст окна, а второй - это контекст в памяти? А вовсе не то, какие битмапы присоединены к этим контекстам? :) Эдакая абстракция. Во втором "буфере" мы картинку отрисовали, а затем одним махом положили ее в первый, в контекст окна. А что там дольше будет происходить с этой картинкой, кто, куда и как будет что-то отправлять, кэшировать и буферизировать - это забота исключительно ОС. И спорить о глубинных процессах в ядре системы и драйверов прикладным программистам - это просто чесание языков, имхо )) Почему можно назвать контекст окна буфером - потому что мы ведь не сами отправляем данные в видеопамять или на обработку видеодрайверу. Мы ложим в одно общее место - в контекст, как во временное хранилище, откуда система уже по своим правилам и алгоритмам отправляет графику дальше, чтобы она попала в оконцовии на монитор. Куда система ложит, и как оттуда доставляет на экран монитора - не наша забота. Наша задача заканчивается на складывании данных в контекст.

> Игорь Шевченко ©   (25.03.08 09:43) [126]
> oxffff ©   (24.03.08 20:54) [119]
>
>
> > То что буфер есть можно узнать по
> > HBM := GetCurrentObject(DC, OBJ_BITMAP).
>
>
> Это не буфер нифига
>
>
> > А то что он необычный по провалу при вызове GetObject
>
>
> Вот потому и проваливается, что не буфер. Купи уже книжку
> Фэня Юаня и прочитай.


Да что вы заладили Фэнь Юань,Фэнь Юань.
Что своей головы нет чтоли?

>Это не буфер нифига.

Зачем он тогда нужен?

Это тот самый буфер на котором осуществляется вывод.
В зависимости от использования способа отрисовки вы он расположен в ведении драйвера, либо в ведении Windows.

> Игорь Шевченко ©   (25.03.08 09:46) [127]
> oxffff ©   (24.03.08 21:19) [123]
>
>
> > Ты рисуешь как раз на этом битмапе.
>
>
> Фига с два. Ты отдаешь команды рисования драйверу. А он
> уже определяет, где и как ему рисовать, то ли вызывать средства
> GDI (точнее, GRE - Graphics Rendering Engine - ядерная часть
> GDI), то ли вызывать аппаратные средства видеоадаптера.
>

>
> Купи уже книжку Фэня Юаня.


Что своей головы нет чтоли?

> Фига с два. Ты отдаешь команды рисования драйверу. А он
> уже определяет, где и как ему рисовать, то ли вызывать средства
> GDI (точнее, GRE - Graphics Rendering Engine - ядерная часть
> GDI), то ли вызывать аппаратные средства видеоадаптера.

Судя по вашим слова в каждом драйвере видеоадаптера есть идентичный код который вызывает ядерные функции GDI в случая отсутствия функциональности.

Вопрос не кажется ли вам это не разумным?
А может более логично GDI опрашивает драйвер на предмет поддержки функциональности аля GetDeviceCaps и в случае неподдержки осуществляет вывод самостоятельно на поверхности (буфере, битмапе, назовите как угодно, но вывод должен на чем то осуществляться)
А в случае аппартаной поддержки window DC битмап является просто оберткой над аппаратным буффером.

> Иначе получается, что аппаратные 3D ускорители занимаются
> анализом изображения нарисованного на битмапе, что есть
> ерунда.

Откуда такой вывод?
Вы рисуете на битмапе в зависимости от расположения он либо в RAM, либо на поверхности front или back VIDEORAM.

>Купи уже книжку Фэня Юаня.

Что говорит Фэня Юань о назначении Bitmap Window DC?

oxffff ©   (25.03.08 13:08) [129]


> Это тот самый буфер на котором осуществляется вывод.


Доказательства будут ?


> Что своей головы нет чтоли?


Есть.


> Зачем он тогда нужен?


а. Почему ты считаешь, что это буфер ?
б. Затем, чтобы GDI не ломался

> Вы рисуете на битмапе в зависимости от расположения он либо
> в RAM, либо на поверхности front или back VIDEORAM.


Нет. Я не рисую на битмапе. На битмапе рисует драйвер, GRE, либо процессор видеоадаптера, которому подаются специальные команды.

Купи уже книжку Фэня Юаня и почитай.

> б. Затем, чтобы GDI не ломался


А с чего ему ломаться?

Этот битмап window DC является Clip частью общего Display DC.
И расположен он либо в RAM, либо VRAM.

> Игорь Шевченко ©   (25.03.08 13:28) [133]
>
> > Вы рисуете на битмапе в зависимости от расположения он
> либо
> > в RAM, либо на поверхности front или back VIDEORAM.
>
>
> Нет. Я не рисую на битмапе. На битмапе рисует драйвер, GRE,
>  либо процессор видеоадаптера, которому подаются специальные
> команды.
>
> Купи уже книжку Фэня Юаня и почитай.


А чем разница? Смысл один и тот же.

oxffff ©   (25.03.08 13:29) [134]


> Этот битмап window DC является Clip частью общего Display
> DC.
> И расположен он либо в RAM, либо VRAM.


Доказательства будут ?

>
> Доказательства будут ?


А вы подумайте зачем нужна эта поверхность.

А еще лучше подумайте на тем, что нельзя заменить через SelectObject
Bitmaps device context.
И я наконец думаю вам все станет понятно.

А в memoryDC кто рисует? Программа или апаратно?
И зачем там нужен битмап? Не догадываетесь?

Да и прочитайте наконец
CreateCompatibleDC

Before an application can use a memory device context for drawing operations, it must select a bitmap of the correct width and height into the device context. This may be done by using CreateCompatibleBitmap to specify the height, width, and color organization required in the function call.

oxffff ©   (25.03.08 13:34) [137]

Я вроде задал конкретный вопрос - доказательства твоему утверждению, что тот битмап, который ты вынимаешь из оконного DC через GetCurrentObject, есть буфер, на котором рисуется изображение, будут ?