Такая проблема, пишу программу обработки сигналов, приходится работать с файлами отсчетов до 200 мб в размере. При прорисовке более 500000 отсчетов в иде графика x,y тормозит жутко, соответственно о нормальном скроллинге и зуме говорить не приходится. Ломал голову и понял что смысла прорисовывать по десять тысячь отсчетов на каждый пиксел экрана не имеет смысла(от этого прорисовка то и тормозит). Сделал так: беру количество пикселей области прорисовки, делю общее количество отсчетов в фаиле на кол-во пикселей получаю энное количество блоков из каждого блока беру максимальное и минимальное значение и прорисовываю для каждого x два значения. До 2-4 миллионов отсчетов работает сносно быстро, если больше то все эти перерасчеты тормозят.Юзаю Cool Edit так там хоть 500 мб фаил загрузи тормозов нет при прорисовке отсчетов (заметил что при открытии в Cool Edit создается фаил дополнительный с какимито значениями).
Может есть у кого идеи по этому поводу? Спасибо.

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

Отсчёт – это пара чисел?
Как рисуете точки? С помощью Windows GDI, функция SetPixel(V)? Это очень медленно. Попробуйте OpenGL, режим GL_POINTS, этот режим используется для рисования точек. Все современные видеокарты достаточно сносно поддерживают OpenGL. По крайней мере, для рисования точек хватит.

S>Ломал голову и понял что смысла прорисовывать по десять тысячь отсчетов на каждый пиксел экрана не имеет смысла(от этого прорисовка то и тормозит).
В компьютерной графике такая ситуация называется «большой overdraw». Например, DirectX help:

DirectX Glossary
…
overdraw
Average number of times that a screen pixel is written to.

S>Сделал так: беру количество пикселей области прорисовки, делю общее количество отсчетов в фаиле на кол-во пикселей получаю энное количество блоков из каждого блока беру максимальное и минимальное значение и прорисовываю для каждого x два значения.
Не понял. То есть отсчёты (они же точки?) распределяются по вертикальным полосам, а потом в каждой полосе рисуются две точки, самая нижняя и самая верхняя?

Проблема не в скорости отрисовки, а в необходимости чтения с диска десятков и сотен мегабайт данных — тут OpenGL не поможет.
Cool Edit создает некие peak файлы, где в сжатом виде хранит нужную для отрисовки вэйвформ информацию, но как именно он это делает — не знаю.

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

DM>Проблема не в скорости отрисовки,
Skyvox (автор корневого сообщения) считает, что в ней:

Ломал голову и понял что смысла прорисовывать по десять тысячь отсчетов на каждый пиксел экрана не имеет смысла(от этого прорисовка то и тормозит).

DM>а в необходимости чтения с диска десятков и сотен мегабайт данных — тут OpenGL не поможет.
Если оперативной памяти много, то даже файл размером 500 мб может влезть в неё целиком.
Насколько я понял, тормозит рисование, а не загрузка данных.

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

DM>Проблема не в скорости отрисовки, а в необходимости чтения с диска десятков и сотен мегабайт данных — тут OpenGL не поможет.
DM>Cool Edit создает некие peak файлы, где в сжатом виде хранит нужную для отрисовки вэйвформ информацию, но как именно он это делает — не знаю.

Вот — вот как раз меня это интересует какие же операции он проводит над оригинальным фаилом и что он скидывает в этот peak файл (при оерациях скролинга и масштабирования он работает именно с этим файлом). облазил уже почти все и нигде внятной информации нет как же отрисовывать эти большие массивы данных без тормозов.

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

S>Вот — вот как раз меня это интересует какие же операции он проводит над оригинальным фаилом и что он скидывает в этот peak файл (при оерациях скролинга и масштабирования он работает именно с этим файлом). облазил уже почти все и нигде внятной информации нет как же отрисовывать эти большие массивы данных без тормозов.

Можно попробовать спектральный анализ — берем FFT, переходим в частотно-фазовый домен. При рисовании ограничиваем полосу — берем только первые N гармоник. N вычисляется так, чтобы период наивысшей гармоники не превышал размера пиксела.

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

S>Вот — вот как раз меня это интересует какие же операции он проводит над оригинальным фаилом и что он скидывает в этот peak файл (при оерациях скролинга и масштабирования он работает именно с этим файлом). облазил уже почти все и нигде внятной информации нет как же отрисовывать эти большие массивы данных без тормозов.

Еще способ, наиболее IMO перспективный — трилинейная фильтрация. Делается файл с исходными N остчетами, N/2 усредненными, N/4 усредненными и т.д. При отображении выбираются два ближайших уровня в зависимости от масштаба, которые усредняются с соответствующими коэффициентами. Ключевое слово — Mipmap. А уж перейти из 2D в 1D — задача даже не стоящая обсуждения.

MS>Можно попробовать спектральный анализ — берем FFT, переходим в частотно-фазовый домен. При рисовании ограничиваем полосу — берем только первые N гармоник. N вычисляется так, чтобы период наивысшей гармоники не превышал размера пиксела.

Будет не то — ограничивая полосу, не найдем максимальное значение сэмплов на отрезке, не сможем корректно отобразить.

MS>Еще способ, наиболее IMO перспективный — трилинейная фильтрация. Делается файл с исходными N остчетами, N/2 усредненными, N/4 усредненными и т.д. При отображении выбираются два ближайших уровня в зависимости от масштаба, которые усредняются с соответствующими коэффициентами. Ключевое слово — Mipmap. А уж перейти из 2D в 1D — задача даже не стоящая обсуждения.

Это уже ближе, только вместо усреднения нужен максимум и минимум.

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

DM>Это уже ближе, только вместо усреднения нужен максимум и минимум.

Не факт, что нужны именно пиковые значения, поскольку они могут очень сильно исказить картину. Вот, к примеру, 10000 отсчетов полной тишины, и один отсчет равный 8000 (треск на виниловой пластинке). Таким образом, если брать только пиковые значения, то при сильном сжатии времени можно вообще ничего не увидеть. Какое-то усреднение все равно необходимо.

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

MS>Здравствуйте, D. Mon, Вы писали:

DM>>Это уже ближе, только вместо усреднения нужен максимум и минимум.

MS>Не факт, что нужны именно пиковые значения, поскольку они могут очень сильно исказить картину. Вот, к примеру, 10000 отсчетов полной тишины, и один отсчет равный 8000 (треск на виниловой пластинке). Таким образом, если брать только пиковые значения, то при сильном сжатии времени можно вообще ничего не увидеть. Какое-то усреднение все равно необходимо.

С одной стороны вы правы, но тут уж стоит выбор или точность отображения или скорость(для моего заказчика важна скорость, хотят как в cool edit). Усреднение пробовал не подойдет, отображаемая картина очень искажается. БПФ считать это еще медленнее будет. А вот насчет mipmap посмотрю... Спасибо.

MS>Не факт, что нужны именно пиковые значения, поскольку они могут очень сильно исказить картину. Вот, к примеру, 10000 отсчетов полной тишины, и один отсчет равный 8000 (треск на виниловой пластинке). Таким образом, если брать только пиковые значения, то при сильном сжатии времени можно вообще ничего не увидеть. Какое-то усреднение все равно необходимо.

Посмотрите на волну в том же cool edit'e или другом редакторе. В большинстве случаев среднее значение сэмплов звука по длинному интервалу — 0. Ибо примерно поровну колеблется то в плюс то в минус. Если один пик на 10000 — это надо показать пользователю, его нельзя "замалчивать", т.к. это щелчок, который будет неприятным сюрпризом.

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

DM>Посмотрите на волну в том же cool edit'e или другом редакторе. В большинстве случаев среднее значение сэмплов звука по длинному интервалу — 0. Ибо примерно поровну колеблется то в плюс то в минус. Если один пик на 10000 — это надо показать пользователю, его нельзя "замалчивать", т.к. это щелчок, который будет неприятным сюрпризом.

Ну, это зависит от того, что же надо изобразить. Если пиковые значения сигнала — то это одно, а если некую огибающую — то это совсем другое. Ну вот еще раз: в ОДИН пиксел попадают 10000 отсчетов. 9999 из них — нули и лишь один, где-то посередине, равен 8000. Такой вот дельта-импульс. Так какое значение надо отображать в этой координате по оси X? Вы с этим сначала определитесь, а потом уж думайте об эффективных методах. В cool edit могут быть весьма нетривиальные методы.