След от таскаемых окошек

> Если свой код есть - надо его заключать в BeginPaint()/EndPaint().

Да, я так и делаю

> Использование прозрачной кисти просто не оставляет видимых следов рисования, но вовсе не значит, что система не тратит время на заполнение дыр прозрачной кистью.

Возможно... но раз нет другого варианта ответа, придется удовлетвориться пока этим :-(

----------------------------

Проделал некоторые эксперименты:

Клиентскую часть окна я обновляю через DX blt()

Причем, то ли это зависит от драйверов видюхи, толи не знаю еще от чего, использую ли я DDBLT_ASYNC или DDBLT_WAIT, эта функция не выходит, пока все не заблитит :-(

Кстати, провел эксперименты по быстродействию блиттинга,
при размере окна 640 x 512, 24 bit, и 666 линиям в развертке (разрешение экрана 800 x 600):

Если я ничего не двигаю на экране, или таскаю что угодно, не задевая мое окно, то blt в окошко занимает ~135 сканлиний (эт ~20% от быстродействия)

Если это чужое окно (я экспериментировал с маленьким окошком от FlashGet) залезает на мое, и двигается по поверхности моего окна, то отработка blt занимает до 300(!) сканлиний, плюс DefWindowProc() тратит на WM_NCPAINT ~80 сканлиний.

Если чужое окно уже (тот же маленький FlashGet) уже покоится на моем окне, то blt занимает ~ 100 сканлиний

Если же на экране всплыла любая надпись посказки над кнопкой или иконкой, то время выполнения blt падает вплоть до ~8 сканлайнов!!!

И откуда такая неразбериха?

 

я что-то так и не понял, где эту нулевую кисть указывать?

 

Nouzui
при регистрации класса окна

 

Нулевая кисть не очень хорошо. Лучше просто NULL. В MSDN сказано если регистрационная кисть NULL, тогда не происходит ничего другого кроме посылания WM_ERASEBKGND. NULL_BRUSH из GetStockObject() это в общем-то не NULL.

 

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

 

Ivan_d
Просто теперь она закрашивает его в прозрачный цвет.

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

 

Да смысл уже не столь в том, почему след, т.к. я от визуальных его последствий избавился.
Вопрос стоит несколько другой, как минимизировать время на отрисовку клиентской части окошка через blt() или другим методом. Текущие результаты (до 50% ресурсов системы) меня не устраивают. (Тесты есть выше)

 

Если есть вопросы по DirectDraw, то лучше разместить их в соответствующем разделе. Хотя как вообще можно минимизировать время отрисовки? В общем случае нужно либо рисовать реже, либо понизить детализацию. И полноэкранные приложения в этом плане тоже выигрывают.

 

Насколько я понял из #21, блиттица rcPaint из PAINTSTRUCT в который попадаёт не всё окно, а только та его часть которая была затёрта, отсюда и "неразбериха" . Когда я экспериментировал с DX блиттингом, то поначалу удивлялся, что скорость сильно зависела от положения окна на экране , оказалось, что при правильном с точки зрения видеоакселератора положении источника\приёмника копирование аппаратное, а при не выровненном - программное

 

Можно поподробнее, когда аппаратное, а когда программное?

p.s.: Блиттю я раз во фрейм целиком клиентскую часть окна.

 

Никакой детализации нет, это просто копирование (без всяких эффектов и масштабирования) картинки раз в кадр.

 

Ivan_d

Тогда почему бы не воспользоваться BitBlt из GDI?

 

Могу поэкспериментировать с bitblt()

Только как мне заменить DX->Blt(&DRect, lpBackSurf, &SRect, DDBLT_WAIT, &ddbltfx) на bitblt()?

При блиттинге через DX используется первичная поверхность с клиппированием по окну. Как мне так же это делать через bitblt()?

 

Ivan_d
Белым цветом не красится. Только что пробовал.
Где-то в другом месте значит была проблема.

 

Может быть проблема в дровах?
Видимо придется мне выдирать кусочки из моего исходника и выкладывать...

 

На моих видеокартах требовалось выравнивание в памяти на 16 байт и такое же для размеров строк, но универсально это или на других акселераторах по другому не знаю.
Кстати при GDI блиттировании принцип тот же.

Я создавал буферный bitmap, и копировал через StretchDIBits в DC из BeginPain.

Может быть дело в том, что:

Уж больно скорость похожа на выборочное обновление окна...

 

По другому кидать в окошко что-либо посреством DX невозможно.

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

Кроме того, совершенно непонятно, почему, когда на экране (в любом месте экрана) показывается всплывающее меню, пусть даже загораживающее часть моего окна - скорость работы bitblt() резко подскакивает (раз в 10)...

 

С тормозами, кажется, разобрался - попробовал на другом компе - все ок.

Видимо из-за моей старинной GeForce2 )

 

Ну почему, можно и самому альтернативное клиппирование сделать.

Для полноэкранного режима - да, для вторичных поверхностей - имхо, а когда у тебя окно расположенное в произвольной области экрана, то тут уж как карта ляжет