Двойная буфферизация(выдернуто из "Вакансия Delphi программист")

← →
oxffff © (2008-03-24 20:55) [120]

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

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

← →
Eraser © (2008-03-24 21:12) [121]

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

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

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

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

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

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

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

← →
Eraser © (2008-03-24 21:14) [122]

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

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

← →
oxffff © (2008-03-24 21:19) [123]

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

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

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

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

← →
oxffff © (2008-03-24 21:21) [124]

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

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

← →
Eraser © (2008-03-25 00:29) [125]

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

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

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

← →
Игорь Шевченко © (2008-03-25 09:43) [126]

oxffff © (24.03.08 20:54) [119]

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

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

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

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

← →
Игорь Шевченко © (2008-03-25 09:46) [127]

oxffff © (24.03.08 21:19) [123]

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

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

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

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

← →
SPeller (2008-03-25 10:41) [128]

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

← →
oxffff © (2008-03-25 13:08) [129]

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

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

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

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

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

← →
oxffff © (2008-03-25 13:17) [130]

> Игорь Шевченко © (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.

← →
oxffff © (2008-03-25 13:25) [131]

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

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

← →
Игорь Шевченко © (2008-03-25 13:26) [132]

oxffff © (25.03.08 13:08) [129]

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

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

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

Есть.

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

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

← →
Игорь Шевченко © (2008-03-25 13:28) [133]

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

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

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

← →
oxffff © (2008-03-25 13:29) [134]

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

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

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

← →
oxffff © (2008-03-25 13:30) [135]

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

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

← →
Игорь Шевченко © (2008-03-25 13:31) [136]

oxffff © (25.03.08 13:29) [134]

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

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

← →
oxffff © (2008-03-25 13:34) [137]

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

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

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

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

← →
oxffff © (2008-03-25 13:38) [138]

Да и прочитайте наконец
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.

← →
Игорь Шевченко © (2008-03-25 13:49) [139]

oxffff © (25.03.08 13:34) [137]

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

← →
Игорь Шевченко © (2008-03-25 13:50) [140]

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.

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

← →
SPeller (work) (2008-03-26 04:24) [141]

> oxffff

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

← →
oxffff © (2008-03-26 07:47) [142]

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

Секрет? :)

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

← →
oxffff © (2008-03-26 07:53) [143]

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

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

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

← →
Игорь Шевченко © (2008-03-26 10:38) [144]

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 этот битмап вполне валидный и имеет некие корректные размеры.

← →
tButton © (2008-03-26 11:21) [145]

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

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

← →
oxffff © (2008-03-26 20:47) [146]

>
> То есть, они предполагают, что для совместимости с кривыми
> программами в 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.

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

расположена

← →
Игорь Шевченко © (2008-03-26 20:50) [147]

oxffff © (26.03.08 20:47) [146]

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

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

> Это IMHO.

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

← →
oxffff © (2008-03-26 20:53) [148]

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

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

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

← →
Fantasist... (2008-03-26 21:53) [159]

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

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

> не обращаясь к другим источникам информации.

Честно говоря хваленный неоднократно тут Фэнь Юань вообще избегает данной темы, так что куда мне уж тут.
А судьи кто?

Двойная буфферизация(выдернуто из "Вакансия Delphi программист") Найти похожие ветки