Здравствуйте, Multy, Вы писали:
M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.
M> Wd — указатель окна M> BMP:= TBitmap.Create; M> Windows.GetClientRect(WD, ARect); M> with BMP, ARect do M> begin M> Width := ARect.Right — ARect.Left; M> Height := ARect.Bottom — ARect.Top; M> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства M> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY); M> end;
M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить? M>Или, может быть, есть другие функции.
а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный
Здравствуйте, korzhik, Вы писали:
K>Здравствуйте, Multy, Вы писали:
M>>Вобщем нужно скопировать содержимое другого окна приложения в битмап.
M>> Wd — указатель окна M>> BMP:= TBitmap.Create; M>> Windows.GetClientRect(WD, ARect); M>> with BMP, ARect do M>> begin M>> Width := ARect.Right — ARect.Left; M>> Height := ARect.Bottom — ARect.Top; M>> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства M>> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY); M>> end;
M>>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить? M>>Или, может быть, есть другие функции.
K>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный
Здравствуйте, Andrew S, Вы писали:
K>>>а color formats буферов совпадают? А то BitBlt не только битмапы копирует, но и конвертирует если color formats разный
M>>Совпадет.
AS>Каким образом измерялась производительность? Непонятно, почему был сделан вывод о медленности BitBlt.
Запомнили время до, сравнили после вот и измерели.
К стати если копировать прото bimap
BitBlt(BMP.Canvas.Handle, 0, 0, Width, Height,BMP.Canvas.Handle , 0, 0, SRCCOPY);
Получаетя в 15 раз быстрее, т.е. дело именно в том, что копируем из окна другого приложения.
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 весьма медленно реализована работа с палитрой при копировании _в_ палитризованный контекст\битмап. Думаю, вряд ли у вас это используется, но вдруг.
Вывод: не рассчитывайте получить производительность там, где ее быть не может.
Здравствуйте, Multy, Вы писали:
M>Вобщем нужно скопировать содержимое другого окна приложения в битмап.
M> Wd — указатель окна M> BMP:= TBitmap.Create; M> Windows.GetClientRect(WD, ARect); M> with BMP, ARect do M> begin M> Width := ARect.Right — ARect.Left; M> Height := ARect.Bottom — ARect.Top; M> WinDC:=GetWindowDC(wd);// получаем для окна контекст устройства M> BitBlt(Canvas.Handle, 0, 0, Width, Height, WinDC, 0, 0, SRCCOPY); M> end;
M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить? M>Или, может быть, есть другие функции.
— если структура приложения позволяет попробуй вызывать фукции типа GetDC, GetWindowDC, один раз (например при старте приложения). так ты получишь частичный выиграш в скорости.
— или попробуй использовать CreateCompatibleDC — тоже должно также помочь
Здравствуйте, Multy, Вы писали:
M>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить? M>Или, может быть, есть другие функции.
Для отдельных случаев — быстрее будет DrawDibDraw
я все свои приложения перевел с BitBlt на DrawDibDraw
M>>Всё хорошо, только BitBlt работает очень медленно, нельзя ли как-то это ускорить? M>>Или, может быть, есть другие функции.
V>Для отдельных случаев — быстрее будет DrawDibDraw V>я все свои приложения перевел с BitBlt на DrawDibDraw
И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.
AS>И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.
The DrawDib functions provide high performance image-drawing capabilities
for device-independent bitmaps (DIBs). DrawDib functions support DIBs
of 8-bit, 16-bit, 24-bit, and 32-bit image depths.
DrawDib functions write directly to video memory. They do not rely on
functions of the graphics device interface (GDI).
AS>>И совершенно напрасно, судя по всему И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.
А>The DrawDib functions provide high performance image-drawing capabilities А>for device-independent bitmaps (DIBs). DrawDib functions support DIBs А>of 8-bit, 16-bit, 24-bit, and 32-bit image depths.
А>DrawDib functions write directly to video memory. They do not rely on А>functions of the graphics device interface (GDI).
Не читайте перед обедом советских газет.
Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.
AS>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты.
А>http://www.morgan-multimedia.com/review.htm
AS>>Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость,
Спасибо, посмеялся. Ветку со ссылками, думаю, можно в юмор Продолжать диалог с господином анонимом намбер 718 возможным не нахожу, от смеха живот заболел. Спасибо, право. Вы продлили мне жизнь как минимум на пару лет. Приходите еще!
Здравствуйте, Andrew S, Вы писали:
AS>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.
AS>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.
K>Вот сделал тест BitBlt и DrawDibDraw: http://rsdn.ru/File/19450/BltTest.rar (на основе http://www.stereopsis.com/blttest/) K>Результаты примерно одинаковые.
О чем я и говорил изначально. Так с чем вы не согласны тогда в моем постинге? Или, наоборот, согласны?
Кстати, тесты не совсем корректны (или совсем некорректны, как угодно). Попробуйте варьировать размеры копируемых ректанглов — на маленьких, например, DrawDib (в правильно приготовленном варианте) будет сливать, поскольку имеет в 1.5 раза больше параметров + вынужден часть из них постоянно анализировать, даже с учетом вызова begin.
Единственная библиотека\интерфейс, которые делают gdi по производительности блиттинга, из тех, что я отсматривал — это allegro. Да и тут, поверьте, разница далеко не в разы. Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую
Здравствуйте, Andrew S, Вы писали:
AS>>>Лучше возьмите в руки более-менее приличный компилятор и напишите тесты. Уверяю, будете удивлены результатом. И это... изучите интерфейсы DDI, прежде чем постить откровенную глупость, пусть даже изначально и написанную не вами.
K>>Вот сделал тест BitBlt и DrawDibDraw: http://rsdn.ru/File/19450/BltTest.rar (на основе http://www.stereopsis.com/blttest/) K>>Результаты примерно одинаковые.
AS>О чем я и говорил изначально. Так с чем вы не согласны тогда в моем постинге? Или, наоборот, согласны?
Я занимаю нейтральную позицию. Пытаюсь для себя выяснить всё до конца.
AS>Кстати, тесты не совсем корректны (или совсем некорректны, как угодно). Попробуйте варьировать размеры копируемых ректанглов — на маленьких, например, DrawDib (в правильно приготовленном варианте) будет сливать, поскольку имеет в 1.5 раза больше параметров + вынужден часть из них постоянно анализировать, даже с учетом вызова begin.
Попробую.
AS>Единственная библиотека\интерфейс, которые делают gdi по производительности блиттинга, из тех, что я отсматривал — это allegro.
Спасибо, посмотрю.
> Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую
А что должно получится? (а то времени особе нет на тесты) Тоже одинаково будет с bitblt?
>> Попробуйте, кстати, directx (ddraw, а не 3d). Еще одно удивление гарантирую
K>А что должно получится? (а то времени особе нет на тесты) Тоже одинаково будет с bitblt?
У меня это медленнее. В общем, если не нужен прямой доступ к видеопамяти, то лучше пользоваться gdi и не ломать голову. Другое дело, что на специфичных задачах gdi может сливать — например, аллегро выигрывает (сильно) на палитре + там удобнее (на мой вкус) интерфейс copy (не blt, а именно copy). Но это все надо тестировать для конкретной задачи. К тому же, еще влияние оказывают видеодрайвера — например, на моей старой машине некоторые результаты наших собственных бенчмарков в качественном плане сильно отличаются. Но то, что gdi и drawDIB пользуются одним низкоуровневым интерфейсом — это даже не обсуждается
Здравствуйте, Andrew S, Вы писали:
AS>Простейший способ проверить — копировать с экрана напрямую (GetDC(NULL), задавая прямоугольки == размерам окна. Если будет такая же производительность — тогда быстрее не получится, даже с использование DirectDraw.
это не верно
DirectDraw может держать картинку в видеопамяти, переключать плоскости (flip chain), делать батч вывод, работать в исключительном выделенном режиме а также синхронизироваться по фронту обратного хода луча. сделайте это в gdi.
И то, и то использует одни и те же сервисы DDI. По-крайней мере, по тестам разница в производительности — доли процента. А bitblt куда как удобнее. DrawDib предназначен несколько для других целей — воспроизведение потока. Впрочем, и тут я в нем уже смысла не вижу.
