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

oxffff ©   (23.03.08 17:24) [40]

А как же буфер, который в каждом DC ? Мой вариант тоже должен работать - ему ж без разницы. Кроме того, регулярно народ спрашивает, как ему получить изображение окна, если оно закрыто другими. В случае наличия буфера такой проблемы быть не должно, верно ?

Этот пример в Висте дает неожиданный интересный результат.

oxffff ©   (23.03.08 17:24) [40]

Кстати, о чем мы вообще спорим ?

Вот из Borland'овской справки: "Double buffering reduces the amount of flicker when the control repaints, but is more memory intensive."

Если у DC есть свой буфер, откуда вообще flicker возникает ?

> А как же буфер, который в каждом DC ?

Common device con
texts 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.

> Если у DC есть свой буфер, откуда вообще flicker возникает
> ?


Если после каждой графической операции DC пересылать подвергнутый операции RECT в VIDEO FRONT Buffer, то будет вам тот же flip.
Другое дело, что видеокарта может брать на себя часть операций поддерживаемых аппаратно, причем формировать изображение тоже в буфере возможно в своей области. Вообщем без DDK спецификации к видеодрайверу уже не обойтись. :)

>Кстати, о чем мы вообще спорим ?

Честно говоря общение куда свалилось не туда.

oxffff ©   (23.03.08 19:10) [44]


> When the application releases a common device context, any
> changes to the default data are lost.


Ну и нафига такой буфер нужен ? :)

Что по-твоему получается - в оконной процедуре по BeginPaint или по GetDC получается общий DC из кэша, на нем чего-то рисуется функциями GDI (надо понимать, в буфер ? ), а после ReleaseDC весь этот буфер пропадает ?

А теперь смотри: В системе масса окон, количество DC (всех, не только общих), всяко меньше количества окон, как они с буферами-то справляются ? Особенно, когда куча потоков лезет за DC в кэш.

> Если у DC есть свой буфер, откуда вообще flicker возникает
> ?


Вопрос в другом, а что если видеокарта не поддерживает часть GDI операций, тогда изображение будет сформировано средствами Windows в буфере и растр просто будет передан в front буфер.

> Если после каждой графической операции DC пересылать подвергнутый
> операции RECT в VIDEO FRONT Buffer, то будет вам тот же
> flip.


Ну да. Я об том же. Вот Борланд (и не только он), сделал возможность формировать изображение в памяти, чтобы потом его одним чохом пересылать в контекст устройства (независимо от аппаратной буферизации, буферизации в ядре, и т.п.)

oxffff ©   (23.03.08 19:22) [47]


> Вопрос в другом, а что если видеокарта не поддерживает часть
> GDI операций, тогда изображение будет сформировано средствами
> Windows в буфере и растр просто будет передан в front буфер.
>


Собственно, по-другому просто нельзя. Разумеется, растр где-то формируется, это еще со времен Windows 3.1 в DDK подробно расписано.

Но из этого не следует, что свой буфер есть у каждого DC, об чем собственно, большевики неоднократно заявляли.

> А теперь смотри: В системе масса окон, количество DC (всех,
>  не только общих), всяко меньше количества окон, как они
> с буферами-то справляются ?


Ничего не мешает Windows поступать очень просто,
не слать WM_PAINT при отсутствии ресурса.
Но тем менее почти 100% окон как раз и являются Common Device Contexts.
Ведь работает же.

> а после ReleaseDC весь этот буфер пропадает ?


Почему пропадает? Вы делаете EraseBackground и вперед с новой песней.

> oxffff ©   (23.03.08 19:28) [51]


В смысле просто очищаете труды предудущей оконной процедуры и заполняете своим контенком

> Но из этого не следует, что свой буфер есть у каждого DC,
>  об чем собственно, большевики неоднократно заявляли.


Во всяком случае bitmap obj есть для display DC. Разговор начался ведь с этого.

oxffff ©   (23.03.08 19:26) [50]


> Ничего не мешает Windows поступать очень просто,
> не слать WM_PAINT при отсутствии ресурса.


Он так не поступает. Он просто не знает в момент посылки WM_PAINT, есть ресурсы или нету, потому что WM_PAINT всегда асинхронно посылается, да еще в очереди находится с низким приоритетом.


> Но тем менее почти 100% окон как раз и являются Common Device
> Contexts.
> Ведь работает же.


Ну да, работает. Потому что операции обрабатываются сами по себе, формируя растр (с учетом всех отсечений), без буфера в каждом DC :)

Собственно, почти вся ядерная часть GDI занимается по преимуществу отсечениями.

нет у окна никаких встроенных битмапов по-умолчанию и точка.

> Eraser ©   (23.03.08 19:36) [55]


Ссылочку на документацию в студию.

> Ссылочку на документацию в студию.

Каку. документацию?? Сказано же: Нет и точка!

> Eraser ©   (23.03.08 19:36) [55]
> нет у окна никаких встроенных битмапов по-умолчанию и точка.
>


procedure TForm1.Button1Click(Sender: TObject);
var Hobj:HGDIOBJ;
   HDC:Thandle;
begin
HDC:=GetDC(Handle);
Hobj:=GetCurrentObject(HDC,OBJ_BITMAP);
if Hobj<>0 then SHOWMESSAGE('ERASER садись. Двойка.');
ReleaseDC(Handle,HDC);
end;

>
> Он так не поступает. Он просто не знает в момент посылки
> WM_PAINT, есть ресурсы или нету, потому что WM_PAINT всегда
> асинхронно посылается, да еще в очереди находится с низким
> приоритетом.


Ну не проблема это. :)