oxffff ©   (25.03.08 13:38) [138]


> 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.


Я тебе открою секрет - при создании MemoryDeviceContext в нем по умолчанию создается монохромный битмап размер 1 х 1 пиксель, на котором рисовать неудобно. Поэтому туда необходимо выбрать битмап с correct width и height.

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

> oxffff

да дался тебе этот фронт буфер :)) доколупался до него как пьяный до радио :)

> Я тебе открою секрет - при создании MemoryDeviceContext
> в нем по умолчанию создается монохромный битмап размер 1
> х 1 пиксель, на котором рисовать неудобно.


Секрет? :)

То есть вы уже признаете, что это буфер на котором вы рисуете (GDI, adapter).

> Игорь Шевченко ©   (25.03.08 13:49) [139]
> oxffff ©   (25.03.08 13:34) [137]
>
> Я вроде задал конкретный вопрос - доказательства твоему
> утверждению, что тот битмап, который ты вынимаешь из оконного
> DC через GetCurrentObject, есть буфер, на котором рисуется
> изображение, будут ?


Отвечу вопросом на вопрос. Зачем  Bitmap в DC?.
Почему SelectObject именно так рабатает?
Вас это не наводит на мысли?
И почему handle из GetCurrentObject не может быть оберткой VIDEO или RAM поверхности?

P.S. Что Фэнь Юань говорит по этому поводу?
Что уже молчит или вы его сами не дочитали? :)

oxffff ©   (26.03.08 07:47) [142]


> Секрет? :)
>
> То есть вы уже признаете, что это буфер на котором вы рисуете
> (GDI, adapter).


ключевое слово в моем посте MemoryDeviceContext

oxffff ©   (26.03.08 07:53) [143]


> Отвечу вопросом на вопрос. Зачем  Bitmap в DC?.
> Почему SelectObject именно так рабатает?
> Вас это не наводит на мысли?
> И почему handle из GetCurrentObject не может быть оберткой
> VIDEO или RAM поверхности?


Что нам пишут разработчики Wine:

"Eurdora 4.x and 5.x crash when handling a WM_PAINT message. The program
gets a hdc from BeginPaint() and does a GetCurrentObject(hdc,OBJ_BITMAP)
on that device context. In wine zero is returned and the program crashes
as a result of that (step tracing it shows some math on it and then uses
the result as a pointer).
The same problem was reported on the developer list in:
http://www.winehq.com/hypermail/wine-devel/2002/11/0599.htm

Since the program does not do anything suspicious between aquiring the
dc handle and the GetCurrentObject, Checking under Windows (Win2000).
I found that GetCurrentObject(,OBJ_BITMAP) on the the dc returned both
by BeginPaint() and CreateDC(), retrieves a non-zero handle. The handle
looks genuine, but the bitmap does not appear to be valid (funny
dimensions and so).
 
My proposed solution is to do what CreatCompatibleDC already does: load
a default bitmap in CreateDC(). This has worked here for a long time
without any aparent problems."

http://www.winehq.org/pipermail/wine-patches/2003-January/005138.html

То есть, они предполагают, что для совместимости с кривыми программами в Windows GDI в DC встроен некий фиктивный объект, дабы программы не ломались. Что вполне соответствует идеологии Windows, вспомнить хотя бы хак для SimCity.

Ты можешь написать программу, которая будет выбирать этот bitmap для разных окон и пытаться узнать его характеристики через GetObject.

Для окон класса tooltip_class32 этот битмап вполне валидный и имеет некие корректные размеры.

> То есть, они предполагают, что для совместимости с кривыми
> программами в Windows GDI в DC встроен некий фиктивный объект,
>  дабы программы не ломались.

вот оно истинное человеколюбие =)
а под линухами - все честно по-пионерски рушится к едрене фене =)

>
> То есть, они предполагают, что для совместимости с кривыми
> программами в Windows GDI в DC встроен некий фиктивный объект,
>  дабы программы не ломались. Что вполне соответствует идеологии
> Windows, вспомнить хотя бы хак для SimCity.


Честно говоря я прочитал текст и не нашел места где они что-то предполагают. :)
Перечитал еще раз и не нашел.

А судя по

>The handle looks genuine, but the bitmap does not appear to be valid (funny
>dimensions and so).

у меня возникают подозрения, что проверять результат функции их не научили.  :)

>дабы программы не ломались.

Я по этому поводу думаю, что это некая поверхность. И скорее всего она расположена в большинстве случаев сегодня в видеопамяти по скольку
современные видеокарты поддерживают аппаратно большинство атомарных графических операций. Если это поверхность является front поверхностью, то мы наблюдает фактически DIRECTDRAW.
Однако в более раннем возрасте эта поверхность могла кочевать из RAM в VRAM в зависимости от поддержки операций. А как известно это дорогая операция. Особенно при обработке WM_PAINT
Думаю было сознательно принято решение ограничить взаимодействие с этой поверхностью для функций SelectObject дабы  
во первых сократить издержки при передачи из VRAM в RAM.
а во вторых формат аппаратной поверхности мог отличать от DIB формата, что приводило бы к задержкам при преобразовании при вызове selectObject
device format <-> DIB формат <-> device format.
А GetObject не мог корретно возвращать информацию об аппаратной поверхности. Поэтому это дело просто запретили.
А Handle оставили поскольку устройство поддерживает RC_BITBLT (Capable of transferring bitmaps).

Это IMHO.



А поскольку аппаратная

расположена

oxffff ©   (26.03.08 20:47) [146]


> Я по этому поводу думаю, что это некая поверхность. И скорее
> всего она расположена в большинстве случаев сегодня в видеопамяти
> по скольку
> современные видеокарты поддерживают аппаратно большинство
> атомарных графических операций. Если это поверхность является
> front поверхностью, то мы наблюдает фактически DIRECTDRAW.
>


А ты не думай. Ты найди подтверждение своим словам.
Я вот искал - не нашел.


> Это IMHO.


Ты тогда подумай, как видеокарты текст выводят. Или тоже рисунок на поверхности анализируют ?

> Или тоже рисунок на поверхности анализируют ?


А зачем проводить анализ?

TEXTCAPS Value that indicates the text capabilities of the device, as shown in the following list:
 TC_CP_STROKE Device is capable of stroke clip precision.
 TC_CR_90 Device is capable of 90-degree character rotation.
 TC_CR_ANY Device is capable of any character rotation.
 TC_EA_DOUBLE Device can draw double-weight characters.
 TC_IA_ABLE Device can italicize.
 TC_OP_CHARACTER Device is capable of character output precision.
 TC_OP_STROKE Device is capable of stroke output precision.
 TC_RA_ABLE Device can draw raster fonts.
 TC_RESERVED Reserved; must be zero.
 TC_SA_CONTIN Device uses any multiples for exact character scaling.
 TC_SA_DOUBLE Device is capable of doubled character for scaling.
 TC_SA_INTEGER Device uses integer multiples only for character scaling.
 TC_SCROLLBLT Device cannot scroll using a bit-block transfer.
This meaning may be the opposite of what you expect.

 TC_SF_X_YINDEP Device can scale independently in the x- and y-directions.
 TC_SO_ABLE Device can draw strikeouts.
 TC_UA_ABLE Device can underline.
 TC_VA_ABLE Device can draw vector fonts.

> Или тоже рисунок на поверхности анализируют ?


Даже если это аппаратно не поддерживается, ничего не мешает делать это программно. Или преобразовывать в набор примитивных операций.
Зачем проводить анализ?

oxffff ©   (26.03.08 20:53) [148]


> А зачем проводить анализ?


Ну если функции GDI рисуют на битмапе, а видеоадаптер сам умеет текст выводить ? Текст, он тоже функциями GDI рисуется. Очевидно, адаптеру придется битмап с рисунком текста анализировать.

Я уже вполне серьезно - почитай Фэня Юаня. Он хорошую книжку написал.

oxffff ©   (26.03.08 20:55) [149]

Вот этот пост к чему ?

И еще: У некоторых окон битмап, получаемый по GetCurrentObject из DC их окна вполне себе валидный. С размерами, возвращаемыми по GetObject.

А у всех остальных он невалидный, и HBITMAP имеет одно и то же значение. Совсем как Stock Object.

oxffff ©   (26.03.08 21:02) [150]

Давай ты уже подтвердишь свою версию ? Примерами, ссылками, дизассемблированием GDI32.DLL и WIN32K.SYS

> Ну если функции GDI рисуют на битмапе, а видеоадаптер сам
> умеет текст выводить ? Текст, он тоже функциями GDI рисуется.
>  Очевидно, адаптеру придется битмап с рисунком текста анализировать.
>


Вы внимательно [146] читали?
Зачем адаптеру проводить анализ? Он не знает что такое текст.
Однако хорошо знает растровую поверхность. Текст программно отрисовался. И поверхность передалась адаптеру.
А в случае аппартной отрисовки поверхности (bitmap) расположен в памяти адаптера.
Зачем проводить анализ?

> Я уже вполне серьезно - почитай Фэня Юаня. Он хорошую книжку
> написал.


Почему Фэнь Юань не затрагивает данный вопрос.
Вы внимательно то сами читали его? :)

> Игорь Шевченко ©   (26.03.08 21:06) [152]
> oxffff ©   (26.03.08 21:02) [150]
>
> Давай ты уже подтвердишь свою версию ? Примерами, ссылками,
>  дизассемблированием GDI32.DLL и WIN32K.SYS


Зачем лезть за int 2e?
Может не стоит из пушки по воробьям?

oxffff ©   (26.03.08 21:23) [153]


> Зачем адаптеру проводить анализ? Он не знает что такое текст.


В том-то и дело, что знает.


>  TC_CR_90 Device is capable of 90-degree character rotation.
>  
>  TC_CR_ANY Device is capable of any character rotation.
>
>  TC_EA_DOUBLE Device can draw double-weight characters.
>
>  TC_IA_ABLE Device can italicize.
>  TC_OP_CHARACTER Device is capable of character output precision.
>  
>  TC_OP_STROKE Device is capable of stroke output precision.
>  


Слово "Device" тебе тут ничего не говорит ?


> Вы внимательно [146] читали?


Да я-то внимательно читал. Только я сильно сомневаюсь в верности изложенного в [146]


> Зачем лезть за int 2e?
> Может не стоит из пушки по воробьям?


GDI32 вообще-то библиотека пользовательского режима, и ряд функций выполняет без обращения к ядру. И часть DC тоже находится в памяти, доступной из пользовательского режима.

Впрочем ладно. Я жду доказательств или опровержений [146].

> В том-то и дело, что знает.


Вы не ответили на вопрос. Зачем проводить анализ изображение в случае программной отрисовки?

>Слово "Device" тебе тут ничего не говорит ?

Так это оно вам должно говорить, я для этого вам их привел.


> Да я-то внимательно читал. Только я сильно сомневаюсь в
> верности изложенного в [146]


Так вы предложите что то свое. Или хотя бы скажите что говорит Фень Юань. Или он как вы тоже молчит.

>GDI32 вообще-то библиотека пользовательского режима, и ряд функций >выполняет без обращения к ядру. И часть DC тоже находится в памяти, >доступной из пользовательского режима.

Вообще то нужная функциональность лезет в ntdll.exe и win32k.sys, то есть через шлюз вызова Int 2e.

> ntdll.exe


ntoskrnl.exe

> Вы внимательно [146] читали?


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