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

← →
@!!ex © (2008-03-22 11:02) [0]

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

← →
@!!ex © (2008-03-22 11:03) [1]

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

← →
Игорь Шевченко © (2008-03-22 11:29) [2]

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

← →
tesseract © (2008-03-22 11:39) [3]

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

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

← →
Игорь Шевченко © (2008-03-22 11:44) [4]

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

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

← →
Дмитрий С (2008-03-22 11:53) [5]

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

← →
Игорь Шевченко © (2008-03-22 12:03) [6]

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

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

← →
Дмитрий С (2008-03-22 12:05) [7]

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

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

← →
Игорь Шевченко © (2008-03-22 12:07) [8]

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

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

← →
Дмитрий С (2008-03-22 12:08) [9]

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

← →
Игорь Шевченко © (2008-03-22 12:08) [10]

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

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

← →
tesseract © (2008-03-22 12:08) [11]

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

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

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

tesseract © (22.03.08 12:08) [11]

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

← →
tesseract © (2008-03-22 12:22) [13]

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

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

← →
Игорь Шевченко © (2008-03-22 12:24) [14]

tesseract © (22.03.08 12:22) [13]

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

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

← →
tesseract © (2008-03-22 12:32) [15]

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

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

← →
oxffff © (2008-03-22 13:55) [16]

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

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

← →
DVM © (2008-03-22 14:01) [17]

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

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

← →
DVM © (2008-03-22 14:02) [18]

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

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

← →
oxffff © (2008-03-22 14:10) [19]

Читать по стили и типы 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.

← →
oxffff © (2008-03-22 14:12) [20]

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

Ты что читать не умеешь?

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.

← →
oxffff © (2008-03-22 14:17) [21]

> DVM © (22.03.08 14:01) [17]
>
> > tesseract © (22.03.08 12:32) [15]
>
> Это GDI использует аппаратное ускорение частично,

С этим я могу согласиться.
Существует возможность использования ускорения за счет делегирования функциональности интерфейса GDI -> драйверу видеокарты, либо непосредственного отображения области видео вывода окна на область RAM.
Но это уже исключение. При таком раскладе разницы между GDI и DirectDraw нет. К этому естественно все и идет. А если видеокарта не поддреживает то область вывода окна формируется в DC. и BITMAP просто передается драйверу вместе с CLIP областью.

← →
DVM © (2008-03-22 14:55) [22]

> oxffff © (22.03.08 14:12) [20]
>
> > У кого есть Bitmap? У DC?
>
>
> Ты что читать не умеешь?

В том то и дело что умею. Пока битмап не выбран в контекст его там нет.

← →
tesseract © (2008-03-22 15:21) [23]

> В том то и дело что умею. Пока битмап не выбран в контекст
> его там нет.

В устройстве нет. В буфере есть. Или ты думаешь, что винда его не кэширует? Двойной буффер и есть в приложении. Один у системы второй у нас. Там на самом деле ещё и HAL лепту вносит.

← →
Игорь Шевченко © (2008-03-22 16:13) [24]

tesseract © (22.03.08 15:21) [23]

> В устройстве нет. В буфере есть. Или ты думаешь, что винда
> его не кэширует?

Кто куда кого кеширует ?

← →
Игорь Шевченко © (2008-03-22 16:15) [25]

oxffff © (22.03.08 14:12) [20]

Эта...а у Device Context"а принтера тоже внутре битмап есть ? А у метафайла ?

← →
oxffff © (2008-03-22 21:05) [26]

> DVM © (22.03.08 14:55) [22]
>
> > oxffff © (22.03.08 14:12) [20]
> >
> > > У кого есть Bitmap? У DC?
> >
> >
> > Ты что читать не умеешь?
>
> В том то и дело что умею. Пока битмап не выбран в контекст
> его там нет.

Точно хорошо читаешь?

см. SelectObject

hgdiobj

(Bitmaps can be selected for memory device contexts only, and for only one device context at a time.)

Так что для остальных DC это сделать нельзя.

← →
oxffff © (2008-03-22 21:15) [27]

> Игорь Шевченко © (22.03.08 16:15) [25]
> oxffff © (22.03.08 14:12) [20]
>
> Эта...а у Device Context"а принтера тоже внутре битмап есть
> ? А у метафайла ?

А какое отношение имеет метафайл к DC?

>Device Context"а принтера тоже внутре битмап есть

Нет, а что окна выводятся на принтер?

← →
oxffff © (2008-03-22 21:19) [28]

> А какое отношение имеет метафайл к DC?

Я имею ввиду какое отношение имеет сериализация графических операций к непосредственному выводу?

> Эта...а у Device Context"а принтера тоже внутре битмап есть
> ? А у метафайла ?

Эмм а при чем тут принтер? Вывод графики через драйвер устройства (vga.dll и т.п.) идет, а DC это абстрактный уровень... В MSDN же описано в About Device Contexts

oxffff © (22.03.08 21:15) [27]

> А какое отношение имеет метафайл к DC?

Он (метафайл) его имеет.

>
> Нет, а что окна выводятся на принтер?

У принтера тоже есть DC

В посте 20 ты написал:

"Ты что читать не умеешь?

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 окна, так и к DC принтера, метафайла и еще чего-нибудь, у чего есть DC.

В связи с этим у меня вопрос, а что у принтера или метафайла внутре его DC тоже битмап имеется, на котором рисуют ? А если принтер PostScript, тогда как ?

oxffff © (22.03.08 21:19) [28]

> Я имею ввиду какое отношение имеет сериализация графических
> операций к непосредственному выводу?

В системе есть очередь операций GDI. Про нее можно прочитать тут:
http://msdn2.microsoft.com/en-us/library/ms534903(VS.85).aspx

← →
Nobody (2008-03-23 01:17) [31]

> Игорь Шевченко © (22.03.08 11:29) [2]
> у DC нету буфера.

У DC есть буффер. Другое дело, что у окна обычно нет постоянного DC (если только ты не указал OWNDC).

Nobody (23.03.08 01:17) [31]

> Другое дело, что у окна обычно нет постоянного DC (если
> только ты не указал OWNDC).

А если я указал CS_OWNDC, то что я могу сделать с буфером ?

>
> В связи с этим у меня вопрос, а что у принтера или метафайла
> внутре его DC тоже битмап имеется, на котором рисуют ? А
> если принтер PostScript, тогда как ?

Я
Отвечаю на ваш вопрос

A printer DC is similar to a display DC in that it is an internal data structure that defines a set of graphic objects and their associated attributes and specifies the graphic modes that affect output. The graphic objects include a pen (for line drawing), a brush (for painting and filling), and a font (for text output).

Как видите про Bitmap ни слова.

А вы попробуйте качестве source для BitBlt указать DC принтера, а в качестве dest Window DC.
Только не забудьте прочитать вот это

BitBlt returns an error if the source and destination device contexts represent different devices. To transfer data between DCs for different devices, convert the memory bitmap to a DIB by calling GetDIBits. To display the DIB to the second device, call SetDIBits or StretchDIBits.

А вы с какой целью упоминули про DC принтера?

oxffff © (23.03.08 16:07) [33]

Если у DC окна есть битмап, на котором все нарисовано, очевидно не составит труда сделать из него BitBlt в другое окно, вне зависимости от того, видно ли исходное окно ?

Давай сделаем простой пример:

unit AppMain; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, ExtCtrls; type TForm1 = class(TForm) ListBox1: TListBox; PaintBox1: TPaintBox; Button1: TButton; procedure FormCreate(Sender: TObject); procedure Button1Click(Sender: TObject); end; var Form1: TForm1; implementation {$R *.dfm} function EnumWindowProc (Wnd: HWND; param: LPARAM): Integer; stdcall; var AClassName: array[0..255] of char; begin with TForm1(param) do begin GetClassName(Wnd, AClassName, SizeOf(AClassName)); ListBox1.Items.AddObject(AClassName, TObject(Wnd)); end; Result := 1; end; procedure TForm1.Button1Click(Sender: TObject); var Wnd: HWND; ADC: HDC; begin if ListBox1.ItemIndex > -1 then begin Wnd := HWND(ListBox1.Items.Objects[ListBox1.ItemIndex]); if IsWindow(Wnd) then begin ADC := GetWindowDC(Wnd); try with PaintBox1.ClientRect do StretchBlt(PaintBox1.Canvas.Handle, Left, Top, Right - Left, Bottom - Top, ADC, 0, 0, Right - Left, Bottom - Top, SRCCOPY); finally ReleaseDC(Wnd, ADC); end; end; end; end; procedure TForm1.FormCreate(Sender: TObject); begin EnumWindows(@EnumWindowProc, LPARAM(Self)); end; end.

И нарисуем из DC каждого окна его картинку.

> Давай сделаем простой пример:

Давайте вы прочитаете документацию для начала. :)

Если это Common Device Contexts. То вы ничего не увидите.
Для начала надо заставить окно отрисоваться в DC.
Либо использовать стиль CS_OWNDC.

Я в разговоре о Double buf разделяю мнение, что буфера действительно два.
Один MемD, второй window DC. В каждом есть битмап, на котором вы рисуете.
Далее этот битмап отправляется драйверу видеокарты который копирует содержимое в Front buffer видеокарты.

> Далее этот битмап отправляется драйверу видеокарты который
> копирует содержимое в Front buffer видеокарты.

То есть получается три буффера.

MEM BITMAP -> WINDOW BITMAP -> VIDEO FRONT BUFFER.

oxffff © (23.03.08 16:55) [35]

> Давайте вы прочитаете документацию для начала. :)
>
> Если это Common Device Contexts. То вы ничего не увидите.
>
> Для начала надо заставить окно отрисоваться в DC.
> Либо использовать стиль CS_OWNDC.

Нет проблем, меняем:

function EnumWindowProc (Wnd: HWND; param: LPARAM): Integer; stdcall; var AClassName: array[0..255] of char; CS: DWORD; begin with TForm1(param) do begin GetClassName(Wnd, AClassName, SizeOf(AClassName)); CS := GetClassLong(Wnd, GCL_STYLE); if (CS and (CS_OWNDC)) <> 0 then ListBox1.Items.AddObject(AClassName, TObject(Wnd)); end; Result := 1; end;

Часть операция может выполняет видеокарта.
см. GetDeviceCaps.

CC_CHORD Device can draw chord arcs.
CC_CIRCLES Device can draw circles.
CC_ELLIPSES Device can draw ellipses.
CC_INTERIORS Device can draw interiors.
CC_NONE Device does not support curves.
CC_PIE Device can draw pie wedges.
CC_ROUNDRECT Device can draw rounded rectangles.
CC_STYLED Device can draw styled borders.
CC_WIDE Device can draw wide borders.
CC_WIDESTYLED Device can draw borders that are wide and styled.

и т.д.

А то что не может быть нарисовано силами видео карты, рисует Windows в
в DC bitmap"e окна.

Это мое IMHO.

До кучи еще тестовое окно запустим:

unit main; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs; type TForm1 = class(TForm) protected procedure CreateParams (var Params: TCreateparams); override; end; var Form1: TForm1; implementation {$R *.dfm} { TForm1 } procedure TForm1.CreateParams(var Params: TCreateparams); begin inherited; Params.WindowClass.style := Params.WindowClass.style or CS_OWNDC; end; end.

> Игорь Шевченко © (23.03.08 17:09) [39]

Снимайте значок МАСТЕРА и передавайте его мне.
Убедитесь, что картинка есть.

Поправьте

with PaintBox1.ClientRect do
StretchBlt(PaintBox1.Canvas.Handle, Left, Top, Right - Left,
Bottom - Top,
ADC, 0, 0, Right - Left, Bottom - Top, SRCCOPY);

на

with Memo1.ClientRect do
StretchBlt(GETDC(Memo1.Handle), Left, Top, Right - Left,
Bottom - Top,
ADC, 0, 0, Right - Left, Bottom - Top, SRCCOPY);

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