[68] Дмитрий С   (21.03.08 23:23)
А вот кстати вопрос, почему буферизация называется двойной. Буфер ведь один:)

[69] oxffff ©   (21.03.08 23:25)

> Буфер ведь один:)

Как один?
MemBitmap и Bitmap окна. Получается два.

Ты что не знал?

[70] Дмитрий С   (21.03.08 23:29)
Ты рисуешь в битмэп, а затем выводишь его в конву окна. Этот битмэп и есть - буфер. Что по твоему еще тут буфер?

> Bitmap окна

Очень смешно:)

[71] oxffff ©   (21.03.08 23:37)
Узнай новое.

A DC is a structure that defines a set of graphic objects and their associated attributes, and the graphic modes that affect output. The graphic objects include a pen for line drawing, a brush for painting and filling, a bitmap for copying or scrolling parts of the screen, a palette for defining the set of available colors, a region for clipping and other operations, and a path for painting and drawing operations. Unlike most of the structures, an application never has direct access to the DC; instead, it operates on the structure indirectly by calling various functions.

(Bitmaps can be selected for memory DCs only, and for only one DC at a time.)  См. SelectObject.

[73] Дмитрий С   (21.03.08 23:46)
А DC - это по твоему окно? :)

[77] oxffff ©   (22.03.08 00:15)
DC - это то что ты видишь в окне.
И то что ты утверждаешь, что у DC нет буфера более чем странно.

Читай про Display Device Contexts

There are three types of DCs for video displays:

Class
Common
Private

[78] oxffff ©   (22.03.08 00:27)
Шах и мат. :)

GDI Technical Articles  GDI Objects
by Ron Gery
Using an output device context (DC) creates a bitmap with the native color format; using a memory DC creates a bitmap that matches the color format of the bitmap currently selected into that DC. (The DC’s color format changes based on the color format of the currently selected bitmap.)

[79] Дмитрий С   (22.03.08 00:32)
DC - это то, посредством чего я рисую на окне, экране, принтере или битмапе, но не то что я вижу. Оно даже и называется Контекст устройства. То что я вижу - это содержимое видеопамяти (ну... в общем случае).

[80] oxffff ©   (22.03.08 00:36)
Скажи зачем в каждом DC есть Bitmap?
Это буфер на котором ты рисуешь.

И возвращаясь к твоему утверждению, почему буфер один для DoubleBuff.
У тебя два DC, и два буфера. Убедил?

[81] Дмитрий С   (22.03.08 00:41)

> Using an output device context (DC) creates a bitmap with
> the native color format; using a memory DC creates a bitmap
> that matches the color format of the bitmap currently selected
> into that DC. (The DC’s color format changes based on the
> color format of the currently selected bitmap.)

Это выдернуто из контекста параграфа про создание битмэпов.

А мы говорим про буферизацию. Для отображения, к примеру, еллипса в, к примеру, окне, между вызовом функции ellipse и появлением, буфер, в виде битмепа, не создается. За исклчением, может быть, окон обработанных функцией updateLayeredWindow.

[82] Дмитрий С   (22.03.08 00:45)

> Скажи зачем в каждом DC есть Bitmap?
> Это буфер на котором ты рисуешь.

В каждом DC нет BitMap-а.

Блин, не кидайся цитатами из спавки, просто почитай.

[83] oxffff ©   (22.03.08 00:51)

> Для отображения, к примеру, еллипса в, к примеру, окне,
> между вызовом функции ellipse и появлением, буфер, в виде
> битмепа, не создается. За исклчением, может быть, окон обработанных
> функцией updateLayeredWindow.
> Защищаться, похоже, ты можешь только кулаками:)
>
> Заканчиваем флуд...

Подожди. Давай уж выясним подробности.

Вопрос первый. Покрепить свои слова выдержкой из MSDN не соизволишь.

>буфер, в виде  битмепа, не создается.

Я тебе еще раз повторяю цитатами из MSDN

Using an output device context (DC) читай дословно Display Device Contexts

creates a bitmap with the native color format; using a memory DC creates a bitmap that matches the color format of the bitmap currently selected into that DC. (The DC’s color format changes based on the color format of the currently selected bitmap.)

Если ты хочешь сказать, что у DC окна нет битмапа (буфера) и весь вывод напрямую производиться в видеопамять (или она mapнута на RAM).
То скажи зачем в Microsoft придумали DIRECTDRAW, если по твоим словам все напрямую.

Я готов продолжить с тобой диалог, если с твоей стороны будут конкретные факты c документации Microsoft, а так с твоей стороны действительно треп уж извини.

[85] Дмитрий С   (22.03.08 00:59)

> oxffff ©

ты опять выдрал предложения из контекста. Лучше не цитировать ничего, чем то, что к тебе не относится.

Вот тут сказано что такое ДЦ и для чего он...
http://msdn2.microsoft.com/en-us/library/ms533227(VS.85).aspx

[87] oxffff ©   (22.03.08 01:05)
Ты по английски читать умеешь из своей ссылки. Там все написано.

A DC is a structure that defines a set of graphic objects and their associated attributes, and the graphic modes that affect output. The graphic objects include a pen for line drawing, a brush for painting and filling, a bitmap for copying or scrolling parts of the screen, a palette for defining the set of available colors, a region for clipping and other operations, and a path for painting and drawing operations.

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

у DC нету буфера. Если бы он был, система бы не посылала WM_PAINT окну всякий раз, когда меняется перекрытие окна другими окнами, за исключением, когда у перекрывающего окна установлен стиль CS_SAVEBITS

> То скажи зачем в Microsoft придумали DIRECTDRAW, если по
> твоим словам все напрямую.


Ты тут всё узлом завязал. К тому-же Explorer начиная с Win98 работает через DirectDraw.

> К тому-же Explorer начиная с Win98 работает через DirectDraw.


Странно. Я в окне Explorer'а вижу стандартные оконные классы - SysListView32, SysTreeView32, Edit...
кто из них научился работать через DirectDraw ?

Читая разное в сети у меня складывается впечатление, что Свойство DoubleBuffered создает эффект двойной буфферизации, хотя принцип несколько инной.
В википедии, кста, есть статья.

Дмитрий С   (22.03.08 11:53) [5]

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

> Игорь Шевченко ©   (22.03.08 12:03) [6]

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

Дмитрий С   (22.03.08 12:05) [7]

Один буфер заполнился - передается на обработку, в это время необходимо ждать, пока он обработается. Чтобы не ждать, заполняется второй буфер, после этого они меняются местами - второй отдается на обработку, первый заполняется.

Ну все. Я так себе это и представлял. Спасибо:)

Кстати, hint: GDI тоже буферизует операции отрисовки. В системе существует очередь операций GDI

И вообще - читать Фень Юаня - программирование графики в Windows.

> Странно. Я в окне Explorer'а вижу стандартные оконные классы
> - SysListView32, SysTreeView32, Edit...кто из них научился
> работать через DirectDraw ?


GDI - читал где-то, году так в 98-м.

tesseract ©   (22.03.08 12:08) [11]

GDI практически всегда работает через те же дырки, что и DirectDraw - оно по другому не умеет просто :)

> GDI практически всегда работает через те же дырки, что и
> DirectDraw - оно по другому не умеет просто :)


Ну немного не так выразился. А ComCtrs - он к GDI типо не относиться ?

tesseract ©   (22.03.08 12:22) [13]


> А ComCtrs - он к GDI типо не относиться ?


Не, не относится.

> Не, не относится.


Гм. после 4-й версии думал что ComCtrls поддеерживает аппаратную отрисовку. 6-я тем более должна держать. Иначе XP томозил бы как win3.11 при отрисовке без аппаратной акселерации. (была такая фича у старых видеокарт - Windows Accelerator, иконки отрисовывал быстрее)

> Игорь Шевченко ©   (22.03.08 11:29) [2]
> у DC нету буфера. Если бы он был, система бы не посылала
> WM_PAINT окну всякий раз, когда меняется перекрытие окна
> другими окнами, за исключением, когда у перекрывающего окна
> установлен стиль CS_SAVEBITS


Да как же нету буфера. У него есть Bitmap. На котором вы рисуете.
Далее этот битмат передается драйверу. вместе с областью отсечения.

> tesseract ©   (22.03.08 12:32) [15]

Это GDI использует аппаратное ускорение частично, а ComCtrls использует GDI. А причина тормозов win3.11 при рисовании в слабых процессорах тех времен.

> Да как же нету буфера. У него есть Bitmap. На котором вы
> рисуете.

У кого есть Bitmap? У DC?

Читать по стили и типы DC

CS_OWNDC
CS_SAVEBITS -

Common Device Contexts
Common device contexts are display DCs maintained in a special cache by the system.
Common device contexts are used in applications that perform infrequent drawing operations.
Before the system returns the DC handle, it initializes the common device context with
default objects, attributes, and modes. Any drawing operations performed by the application
use these defaults unless one of the GDI functions is called to select a new object,
change the attributes of an existing object, or select a new mode.

Because only a limited number of common device contexts exist, an application should
release them after it has finished drawing. When the application releases a common device
context, any changes to the default data are lost.

Private Device Contexts
Private device contexts are display DCs that, unlike common device contexts,
retain any changes to the default dataeven after an application releases them.
Private device contexts are used in applications that perform numerous drawing
operations such as computer-aided design (CAD) applications, desktop-publishing applications,
drawing and painting applications, and so on. Private device contexts are not part
of the system cache and therefore need not be released after use.
The system automatically removes a private device context after the last window
of that class has been destroyed.

An application creates a private device context by first specifying the
CS_OWNDC window-class style when it initializes the style member of the WNDCLASS
structure and calls the RegisterClass function.
(For more information about window classes, see Window Classes.)

After creating a window with the CS_OWNDC style,
an application can call the GetDC, GetDCEx, or BeginPaint function
once to obtain a handle identifying a private device context.
The application can continue using this handle (and the associated DC) until it deletes
the window created with this class. Any changes to graphic objects and their attributes,
or graphic modes are retained by the system until the window is deleted.