K>>>>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный

M>>>Совпадет.

AS>>Каким образом измерялась производительность? Непонятно, почему был сделан вывод о медленности BitBlt.

M>Запомнили время до, сравнили после вот и измерели.

M>К стати если копировать прото bimap
M>BitBlt(BMP.Canvas.Handle, 0, 0, Width, Height,BMP.Canvas.Handle , 0, 0, SRCCOPY);
M>Получаетя в 15 раз быстрее, т.е. дело именно в том, что копируем из окна другого приложения.

Не только в этом. Во-первых, вы копируете с экрана, а не просто перегоняете память\память, как в случае TBitmap->TBitmap (кажется, там по умолчанию DIB секции, хотя могу и ошибаться). Естественно, что для большинства видеоадаптеров это довольно медленно. Хотя с приходом PCI-E ситуация изменилась кардинально — теперь считывать из видеопамяти быстрее, чем копировать в нее (собственно, так и должно быть — чтение завсегда было быстрее записи при работе с системной памятью при прочих равных). Во-вторых, тот DC, с которого копируете вы, на самом деле обычный кусок экранного DC, с установленным клиппингом и регионом окна (если есть, конечно). Т.о., кроме просто копирования, в худшем случае gdi приходится еще и клиппинг делать. Это хотя и быстро, но время все-равно занимает.
Простейший способ проверить — копировать с экрана напрямую (GetDC(NULL), задавая прямоугольки == размерам окна. Если будет такая же производительность — тогда быстрее не получится, даже с использование DirectDraw. Да, еще у gdi весьма медленно реализована работа с палитрой при копировании _в_ палитризованный контекст\битмап. Думаю, вряд ли у вас это используется, но вдруг.

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