Вот эту самую пилу. Сейчас рисую с помошью PolyPolyline, около пары тысяч точек, лини по 3-5 пикселей. Масштаб такой, что точка не перерисовывается, волны отделены друг от друга. Окошко 400х200, мигает ЖУТКО!!!
Чем рисовать эту дрянь, что не мигала? Буферизацию делал, не помогло. Дело не в том, что мигает светлый задний фон, а именно рисуется тормозно.

A>Вот эту самую пилу. Сейчас рисую с помошью PolyPolyline, около пары тысяч точек, лини по 3-5 пикселей. Масштаб такой, что точка не перерисовывается, волны отделены друг от друга. Окошко 400х200, мигает ЖУТКО!!!
A>Чем рисовать эту дрянь, что не мигала? Буферизацию делал, не помогло. Дело не в том, что мигает светлый задний фон, а именно рисуется тормозно.

Может проще прямо в bitmap на MemoryDC рисовать, а затем BitBlt'ить на основной DC. Тогда и моргать ничего не будет, и рисоваться шустрее станет.

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

A>>Буферизацию делал, не помогло.
L>Может проще прямо в bitmap на MemoryDC рисовать, а затем BitBlt'ить на основной DC. Тогда и моргать ничего не будет, и рисоваться шустрее станет.

A>>>Буферизацию делал, не помогло.

Может покажите как делали? Раз мигает.

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

A>>>>Буферизацию делал, не помогло.

L>Может покажите как делали? Раз мигает.

Собственно там очень малло

//
for (LONG index = 0; index < widthSample; index++)
    {
        // Local variables
        float sample;
        // Code
        _stream_seek(CStorage, (DWORD)(sizeof(sample)*(mediaParameters.channelNumber - 1)), FILE_CURRENT, NULL);
        CStorage->Read(&sample, sizeof(sample), NULL);
        CPointList[index].x = (LONG)(lpRect->left + index*widthPixel/widthSample);
        CPointList[index].y = (LONG)(lpRect->top + (LONG)(((AKOFF_REAL)(1.0) - sample)*heightPixel));
    }
// Local variables
C_Pen CPen(PS_SOLID, 1, RGB(0, 0, 255));
HGDIOBJ hObjectPen = CDC.SelectObject(CPen);
// Code
CDC.Polyline(CPointList.Data(), CPointList.Size());// ****************
CDC.SelectObject(hObjectPen);

Тормоза в линии помеченно звёздочками. Рисую как прямо на экран, так и в memory DC — по фигу, скорость одинаковая.

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

[]

Может данные сначала зачитать в буфер?

A>>>>>Буферизацию делал, не помогло.

Не помогло от моргания или скорости?
От скорости и не должно помогать.

A>

A>CDC.Polyline(CPointList.Data(), CPointList.Size());// ****************
A>

A>Тормоза в линии помеченно звёздочками. Рисую как прямо на экран, так и в memory DC — по фигу, скорость одинаковая.

По поводу скорости:
Как я уже сказал, лучше использовать прямое обращение к памяти, то-есть работать с DIBSECTION.
Такие функции, как SetPixel/GetPixel и тот же Polyline, очень медленные при работе с DC (любым, здесь нет разницы MemoryDC это или нет). Каждый раз когда вызывается SetPixel, происходит переход в режим ядра, где уже обрабатывается сама прорисовка. Такое переключение на каждый пиксел очень ресурсоёмко. Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

По поводу моргания:
Покажите код буферизации и прорисовки.

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

[]

L>По поводу скорости:
L>Как я уже сказал, лучше использовать прямое обращение к памяти, то-есть работать с DIBSECTION.
L>Такие функции, как SetPixel/GetPixel и тот же Polyline, очень медленные при работе с DC (любым, здесь нет разницы MemoryDC это или нет).

Т.е. совсем нет? Откуда дровишки?

L>Каждый раз когда вызывается SetPixel, происходит переход в режим ядра, где уже обрабатывается сама прорисовка.
L>Такое переключение на каждый пиксел очень ресурсоёмко. Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

Разве что только на совсем древних карточках, да и то вряд-ли...

L>>По поводу скорости:
L>>Как я уже сказал, лучше использовать прямое обращение к памяти, то-есть работать с DIBSECTION.
L>>Такие функции, как SetPixel/GetPixel и тот же Polyline, очень медленные при работе с DC (любым, здесь нет разницы MemoryDC это или нет).

P> Т.е. совсем нет? Откуда дровишки?

При чём тут дровишки?
Я про то, что подсистема Win32 (Csrss.exe) находится в ядре в Win2000.
И при вызове SetPixel вверху стэка происходит прерывание ("int 0x2e" для x86), срабатывает ловушка (trap), которая заставляет выполняемый поток переключиться в режим ядра и войти в диспетчер системных сервисов, а далее по номеру (регистр EAX) вызывается уже сам системный сервис, то-есть обработчик для SetPixel внутри Csrss.exe. Так вот, вся эта операция очень ресурсоёмкая, особенно переключение в режим ядра. А потому работать попиксельно через SetPixel с графикой очень неэффективно.

L>>Каждый раз когда вызывается SetPixel, происходит переход в режим ядра, где уже обрабатывается сама прорисовка.
L>>Такое переключение на каждый пиксел очень ресурсоёмко. Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

P>Разве что только на совсем древних карточках, да и то вряд-ли...

При чём тут карточки? См. выше.

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

L>>>По поводу скорости:
L>>>Как я уже сказал, лучше использовать прямое обращение к памяти, то-есть работать с DIBSECTION.
L>>>Такие функции, как SetPixel/GetPixel и тот же Polyline, очень медленные при работе с DC (любым, здесь нет разницы MemoryDC это или нет).

P>> Т.е. совсем нет? Откуда дровишки?

L>При чём тут дровишки?

Откуда сведения — так понятнее?

L>Я про то, что подсистема Win32 (Csrss.exe) находится в ядре в Win2000.

Вообще то мы рассматриваем графическую подсистему. Которая уже давно не часть подсистемы Win32.
Конечно, вне всякого сомнения, win32k.sys выполняется в режиме ядра.

[]

L>А потому работать попиксельно через SetPixel с графикой очень неэффективно.

Вне всякого сомнения. Я оспариваю

здесь нет разницы MemoryDC это или нет

В случае, если поверхность находиться под управлением GDI (напр. для стандартных форматов DIB), то драйвер вообще может не учавствовать в обработке большинства граф. операций, не говоря уж о том, чтобы непосредственно обращаться к видеоадаптеру.

L>>>Каждый раз когда вызывается SetPixel, происходит переход в режим ядра, где уже обрабатывается сама прорисовка.

К слову сказать, сие происходит в большинстве случаев, не только при вызове SetPixel.

L>>>Такое переключение на каждый пиксел очень ресурсоёмко. Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

P>>Разве что только на совсем древних карточках, да и то вряд-ли...

L>При чём тут карточки? См. выше.

Не думаю, что на сегодняшний день существуют реализации Polyline via SetPixel.
Вывод линий давным давно уже сделан аппаратным, как впрочем и большинства 2d графики.
Кстати, вообще не понимаю, на кой хрен ее реализовывать via SetPixel, когда можно LineTo?
Или ты под SetPixel понимаешь не API ф-ю SetPixel, а установку пиксела как таковое?

L>>Я про то, что подсистема Win32 (Csrss.exe) находится в ядре в Win2000.

P>Вообще то мы рассматриваем графическую подсистему. Которая уже давно не часть подсистемы Win32.
P>Конечно, вне всякого сомнения, win32k.sys выполняется в режиме ядра.

Я описывал механизм системного вызова как таковой. До того куда этот вызов уже потом пойдёт в какую подсистему и в какой драйвер речь не шла.

L>>А потому работать попиксельно через SetPixel с графикой очень неэффективно.

P>Вне всякого сомнения. Я оспариваю
P>

P>здесь нет разницы MemoryDC это или нет

P>В случае, если поверхность находиться под управлением GDI (напр. для стандартных форматов DIB), то драйвер вообще может не учавствовать в обработке большинства граф. операций, не говоря уж о том, чтобы непосредственно обращаться к видеоадаптеру.

Ещё раз, я тут имел в виду, что тормоза при использовании SetPixel будут как для MemoryDC, так и для экранного. Так как эти тормоза имеют природу, которую я описал и к типу DC это не имеет никакого отношения.

А если, более глобально, что вообще все операции над DC как таковые. То тут конечно имеет уже разница с каким DC вы работаете.

L>>>>Каждый раз когда вызывается SetPixel, происходит переход в режим ядра, где уже обрабатывается сама прорисовка.

P>К слову сказать, сие происходит в большинстве случаев, не только при вызове SetPixel.

А кто спорит?

L>>>>Такое переключение на каждый пиксел очень ресурсоёмко. Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

P>Не думаю, что на сегодняшний день существуют реализации Polyline via SetPixel.
P>Вывод линий давным давно уже сделан аппаратным, как впрочем и большинства 2d графики.
P>Кстати, вообще не понимаю, на кой хрен ее реализовывать via SetPixel, когда можно LineTo?
P>Или ты под SetPixel понимаешь не API ф-ю SetPixel, а установку пиксела как таковое?

Я SetPixel в качестве примера взял. А вообще через что работает Polyline нужно проверять.

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

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

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

[]

L>Ещё раз, я тут имел в виду, что тормоза при использовании SetPixel будут как для MemoryDC, так и для экранного. Так как эти тормоза имеют природу, которую я описал и к типу DC это не имеет никакого отношения.

Конечно будут, кто же спорит. Все зависти от "качества" тормозов.
Т.е. я таки настаиваю, что разница (memory vs screen) есть.

Хотя, вопрос безусловно интересный. Кто-нибудь из гуру объяснит популярно?
Как я понял, в случае ежели поверхность управляется GDI (доп. драйвер отдал все на откуп GRE), линия выводиться средствами GDI (cpu),
а потом идет билттинг, т.е. адаптер просто копирует полученную поверхность в буфер кадров.
В другом случае — линия выводиться аппаратно (gpu).
Ежели линий много, будет часто дергаться шина, и по-идее, это будет медленнее чем разовый блиттинг, несмотря на аппаратную реализацию.
А ежели поверхность управляется устройством? В этом случае как?

L>А если, более глобально, что вообще все операции над DC как таковые. То тут конечно имеет уже разница с каким DC вы работаете.

Дык ежу понятно, что обрабатывать каждый пиксел в виде uset<->system несколько накладно.

[]

P>>Не думаю, что на сегодняшний день существуют реализации Polyline via SetPixel.
P>>Вывод линий давным давно уже сделан аппаратным, как впрочем и большинства 2d графики.
P>>Кстати, вообще не понимаю, на кой хрен ее реализовывать via SetPixel, когда можно LineTo?
P>>Или ты под SetPixel понимаешь не API ф-ю SetPixel, а установку пиксела как таковое?

L>Я SetPixel в качестве примера взял. А вообще через что работает Polyline нужно проверять.

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

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

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

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

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

P>[]

L>>Ещё раз, я тут имел в виду, что тормоза при использовании SetPixel будут как для MemoryDC, так и для экранного. Так как эти тормоза имеют природу, которую я описал и к типу DC это не имеет никакого отношения.

P>Конечно будут, кто же спорит. Все зависти от "качества" тормозов.
P>Т.е. я таки настаиваю, что разница (memory vs screen) есть.

P>Хотя, вопрос безусловно интересный. Кто-нибудь из гуру объяснит популярно?
P>Как я понял, в случае ежели поверхность управляется GDI (доп. драйвер отдал все на откуп GRE), линия выводиться средствами GDI (cpu),
P>а потом идет билттинг, т.е. адаптер просто копирует полученную поверхность в буфер кадров.
P>В другом случае — линия выводиться аппаратно (gpu).
P>Ежели линий много, будет часто дергаться шина, и по-идее, это будет медленнее чем разовый блиттинг, несмотря на аппаратную реализацию.
P>А ежели поверхность управляется устройством? В этом случае как?

А разве MemDC управляется не устройством? Тут по идее разницы не будет, что DC, что MemDC (пока памяти у карты хватает). А по поводу дерганья шины — вопрос мутный.. Мне так кажется,что это лучше чем рисование GRE (в любом случае аппратная реализация намного быстрее софтовой).

L>>А если, более глобально, что вообще все операции над DC как таковые. То тут конечно имеет уже разница с каким DC вы работаете.

P>Дык ежу понятно, что обрабатывать каждый пиксел в виде uset<->system несколько накладно.

P>[]

P>>>Не думаю, что на сегодняшний день существуют реализации Polyline via SetPixel.
P>>>Вывод линий давным давно уже сделан аппаратным, как впрочем и большинства 2d графики.
P>>>Кстати, вообще не понимаю, на кой хрен ее реализовывать via SetPixel, когда можно LineTo?
P>>>Или ты под SetPixel понимаешь не API ф-ю SetPixel, а установку пиксела как таковое?

L>>Я SetPixel в качестве примера взял. А вообще через что работает Polyline нужно проверять.

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

А по поводу рисования так и не понял — рисуется медленно или мигает?
Если мигает — так надо в MemDC рисовать, а если тормозит — проверить значения координат. Если они отрицательные или офигенно большие — будет тормозить однозначно (не знаю с чем это связано, очевидно конвейер отсечений напрягается). Еще очень медленно рисует на машинах со встроенной видео на борту. Такое дело как рисование ОЧЕНЬ сильно зависит от видео и драйвера.

H e l l o, adontz!

a> делал, не помогло. Дело не в том, что мигает светлый задний фон, а
a> именно рисуется тормозно.

А как вы обрабатываете WM_ERASEBKGND?
Чтобы фон не затирал нарисованное нужно в обработчике сообщения
вернуть не ноль.

--
Всего хорошего, Слава v0.666 beta (http://slava.users.otts.ru)
-= Не тратьте силы, возьмите молоток побольше. =-

L>Polyline, подозреваю, просто делает серию вызовов SetPixel со всеми вытекающими.

Нет, PolyPolyline работает по сравнению с SetPixel/LineTo явно быстрее.

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

SA>А как вы обрабатываете WM_ERASEBKGND?

HBRUSH у класса окна NULL, так фона никакого у меня нет. Я сразу делаю BitBlt новой картинки поверх старой.

H e l l o, kliff!

k> Такое дело как
k> рисование ОЧЕНЬ сильно зависит от видео и драйвера.

ИМХО не менее сильно это зависит и от того как рисовать. Ведь можно
сдуру рисовать все подряд, даже то, что не будет видно, или уже видно.

--
Всего хорошего, Слава v0.666 beta (http://slava.users.otts.ru)
-= Никто не знает столько, сколько не знаю я! =-

H e l l o, adontz!

SA>> А как вы обрабатываете WM_ERASEBKGND?
a> HBRUSH у класса окна NULL, так фона никакого у меня нет. Я сразу
a> делаю BitBlt новой картинки поверх старой.

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

--
Всего хорошего, Слава v0.666 beta (http://slava.users.otts.ru)
-= Ничто так не облегчает понимание политики кнута, как пряник. =-