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

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

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

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

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

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

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

Здравствуйте, 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 рисовать, а если тормозит — проверить значения координат. Если они отрицательные или офигенно большие — будет тормозить однозначно (не знаю с чем это связано, очевидно конвейер отсечений напрягается). Еще очень медленно рисует на машинах со встроенной видео на борту. Такое дело как рисование ОЧЕНЬ сильно зависит от видео и драйвера.

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

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

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

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

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

Вот эту самую пилу. Сейчас рисую с помошью 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 или производные от него, то тут уже другое дело. Вот это нужно проверять.

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)
-= Ничто так не облегчает понимание политики кнута, как пряник. =-

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

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

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

Вроде так.

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

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

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

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

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

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

ЗЫ: А что, разве создание 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.

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

Здравствуйте, 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.