Здравствуйте, Slava Antonov, Вы писали:

SA>А как у вас организовано рисование?
SA>Через BeginPaint/EndPaint?

Делаю BeginPaint, потом CreateCompatibleDC и CreateCompatibleBitmap, потом SelectObject один в другой, далее рисую в CompatibleDC, потом BitBlt, EndPaint и удаляю Compatible DC и Bitmap.

Вроде так.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Slava Antonov, Вы писали:

SA>>А как у вас организовано рисование?
SA>>Через BeginPaint/EndPaint?

A>Делаю BeginPaint, потом CreateCompatibleDC и CreateCompatibleBitmap, потом SelectObject один в другой, далее рисую в CompatibleDC, потом BitBlt, EndPaint и удаляю Compatible DC и Bitmap.

Не надо каждый раз создавать и удалять compatible DC и bitmap. Создай один раз и используй повторно. Bitmap придется пересоздавать при изменении размеров окна, но это все равно реже, чем на каждое рисование.

Здравствуйте, Alex Fedotov, Вы писали:

AF>Не надо каждый раз создавать и удалять compatible DC и bitmap. Создай один раз и используй повторно. Bitmap придется пересоздавать при изменении размеров окна, но это все равно реже, чем на каждое рисование.

Безусловно. Тогда я его Compatible к экрану сделаю. Спасибо за идею!

Здравствуйте, Alex Fedotov, Вы писали:

AF>Не надо каждый раз создавать и удалять compatible DC и bitmap. Создай один раз и используй повторно. Bitmap придется пересоздавать при изменении размеров окна, но это все равно реже, чем на каждое рисование.

Помогло! Ещё раз спасибо!

ЗЫ: А что, разве создание DC и bitmap такие тяжёлые операции? А я и не знал, думал просто память выделяется

A>Делаю BeginPaint, потом CreateCompatibleDC и CreateCompatibleBitmap, потом SelectObject один в другой, далее рисую в CompatibleDC, потом BitBlt, EndPaint и удаляю Compatible DC и Bitmap.

Сразу надо было это показывать. Просил же исходник показать. Так нет же, вырежут кусок, самый маленький и ненужный, и показывают.

Здравствуйте, kliff, Вы писали:

[]

P>>Ежели линий много, будет часто дергаться шина, и по-идее, это будет медленнее чем разовый блиттинг, несмотря на аппаратную реализацию.
P>>А ежели поверхность управляется устройством? В этом случае как?

K>А разве MemDC управляется не устройством?

Как я понял — не обязательно. К тому же, даже если и управляется, то драйвер может просто отфутболивать вызовы взад, т.е. тому же GRE.

K>Тут по идее разницы не будет, что DC, что MemDC (пока памяти у карты хватает). А по поводу дерганья шины — вопрос мутный..

Ага, особенно если учесть то, что запросы могут кэшироваться.

K>Мне так кажется,что это лучше чем рисование GRE (в любом случае аппратная реализация намного быстрее софтовой).

Хм, не факт. Я сильно спорить не буду, поскольку в эти дебри не вдавался (почему собст. и интересуюсь, может кто популярно объяснит), но помниться читал мельком где-то на геймерских (в смысле разрабочиков) сайтах (на gamedev вроде), что, к примеру, разницы между аппаратной и софтверной реализацией vertex shaders практически нет.

[]

K>А по поводу рисования так и не понял — рисуется медленно или мигает?

Это к автору. Мне почему-то показалось, что проблема вовсе даже не в графике (у меня в проекте есть что-то похожее, не WAV но типа того, дак ничего
не мигает), а в

_stream_seek(CStorage, (DWORD)(sizeof(sample)*(mediaParameters.channelNumber - 1)), FILE_CURRENT, NULL);
CStorage->Read(&sample, sizeof(sample), NULL);

поскольку автор не уточнил кто такой CStorage, я предположил что это файл, и стоило бы подумать над предвыборкой, а не дергать его на каждый sample.

K>Если мигает — так надо в MemDC рисовать, а если тормозит — проверить значения координат. Если они отрицательные или офигенно большие — будет тормозить однозначно (не знаю с чем это связано, очевидно конвейер отсечений напрягается).



K>Еще очень медленно рисует на машинах со встроенной видео на борту. Такое дело как рисование ОЧЕНЬ сильно зависит от видео и драйвера.

Не думаю что на столько...

Здравствуйте, kliff, Вы писали:

[]

P>>Я почти уверен, что (как бы это выразиться?) ни через что. В смысле алгоритм такой же как у LineTo, без дополнительных вызовов.
P>>В крайнем случае, через серию вызовов внутренней реализации LineTo.

K>точно, драйвер экспортирует только одну функцию рисования линий — DrvLineTo.

Кстати, интересно, PolyLine убирает "лишние" промежуточные точки? Имеется в видо то, что если несколько точек подряд лежат на одной прямой, то промежуточные можно выкинуть, дабы не напрягать подсистему. Мне помниться это сильно помогло, правда не в случае с видео, а с принтером. Драйвер принтера этой проблемой не заморачивался, и просто пулял все подряд в принтер. Но с принтером проще, там легко можно посомтреть что конкретно и в каком виде идет в девайс...

Здравствуйте, Patalog, Вы писали:

P>Это к автору. Мне почему-то показалось, что проблема вовсе даже не в графике (у меня в проекте есть что-то похожее, не WAV но типа того, дак ничего
P>не мигает), а в
P>

P>_stream_seek(CStorage, (DWORD)(sizeof(sample)*(mediaParameters.channelNumber - 1)), FILE_CURRENT, NULL);
P>CStorage->Read(&sample, sizeof(sample), NULL);
P>

P>поскольку автор не уточнил кто такой CStorage, я предположил что это файл, и стоило бы подумать над предвыборкой, а не дергать его на каждый sample.

На самом деле это целиком в памяти и хотя интерфейс ужасный, всё не так уж и медленно.

Здравствуйте, Patalog, Вы писали:

P>Кстати, интересно, PolyLine убирает "лишние" промежуточные точки?

Windows 2003 — НЕТ. Пришлось убирать руками, производительность при этом сильно возрасла.

Здравствуйте, adontz, Вы писали:

[]

P>>Кстати, интересно, PolyLine убирает "лишние" промежуточные точки?

A>Windows 2003 — НЕТ. Пришлось убирать руками, производительность при этом сильно возрасла.

Т.е. даже на графике (имеется в виду в противоположность принтеру) это сильно заметно? Запишем.
А то я как-то в этом случае не сильно заморачивался... А насколько сильно? Заметно невооруженным взглядом или профилировал?

Кстати, попробуй еще SetDCPenColor вместо CPen/SelectObject, ежели отрисовывается несколько "каналов" с разными цветами, то должно немного помочь.

L>Вопрос не в том, что вызывается, а как вызывается.
L>Если это один системный вызов, а уже в ядре идёт построение и отрисовка всех линий через внутренние LineTo, то это одно. А если алгоритм работает в user-mode, и на каждую линию дёргает системный LineTo или производные от него, то тут уже другое дело. Вот это нужно проверять.

DrvStrokePath

Здравствуйте, Patalog, Вы писали:

P>Заметно невооруженным взглядом или профилировал?

Ну в результате оптимизации у меня количество точек уменьшалось раз 5, глазом очень даже заметно.

P>Кстати, попробуй еще SetDCPenColor вместо CPen/SelectObject, ежели отрисовывается несколько "каналов" с разными цветами, то должно немного помочь.

Да нет, цвет один.

Здравствуйте, adontz, Вы писали:

A>ЗЫ: А что, разве создание DC и bitmap такие тяжёлые операции? А я и не знал, думал просто память выделяется

А кто сказал, что выделение памяти — легкая операция?

Здравствуйте, Lopcom, Вы писали:

P>>Вывод линий давным давно уже сделан аппаратным, как впрочем и большинства 2d графики.

L>То, что для 2D сделана аппаратная реализация это понятно.
L>Тут другое интересно, если Polyline действительно имеет аппаратную поддержку, то почему тогда такие тормоза? Сдаётся мне, что её просто нет. Во всяком случае на машине испытуемого. Хотя сама сервисная функция может и зарегистрирована. Нужно проверять.
Судя по драйверам существуют аппаратные реализации LineTo и StrokePath. PolyLine не заметил, но очевидно что PolyLine рисуется LineTo.

Сейчас уже, наверное, вместо прерывания используется специальная команда SysEnter.

ЕК>Сейчас уже, наверное, вместо прерывания используется специальная команда SysEnter.

Насколько я знаю, это начиная с XP такое.