Построение графиков с большим количеством точек (Builder6)

Добрый вечер форумчане!
Передо мной возникла задача построения графиков с большим количеством точек (> 1,5 млн) + возможность увеличения и секторное выделение графиков.
Если я решаю свою задачу через TChart, то построение в компоненте идет порядка 8 сек. И это для меня много)
Из этих 8 секунд: 1-1,5 сек затрачивается на чтение данных из файла в динамические массивы, а вот остальное время занимает само построение графиков.
Пробовал рисовать руками посредстваом Image->Canvas... получилось порядка 7 секунд на антологичную задачу + гемор при разработке функций масштабирования.
Пробовал юзать dislin, получается аналогично не быстро + еще больше сложностей с динамическими манипуляциями графиком...
В общем, может есть какие-нибудь идеи на этот счет?
P.S. В работе использую C++ Builder6.
Всем спасибо!

0

что на счет того чтобы создать двумерный массив и построить по нему линию тренда?

1

Сообщение от QWIPQ что на счет того чтобы создать двумерный массив и построить по нему линию тренда?

Добрый вечер!
Погуглил про линию тренда. Мне нужно построить полноценный график, так как необходимо визуальное определение флуктуаций значений (порой в широком диапазоне). Линия тренда - конечно инструмент технического анализа, но для моих целей он не подходит.

0

filzer, я бы не рисовал поточечно - а сделал бы так:
- создал 2 массива с числом элементов, равных числу горизонтальных точек той области, где будет отрисован сам график.
- пробежал бы по всем точкам, пересчитывая их горизонтальные координаты в индексы точек массива, и набрал бы статистику по вертикальным мин, макс-значениям (тоже пересчитанным из реальных значений в координаты точек на экране) (для этого и нужно 2 массива - минимумы и максимумы положить), соответствующим горизонтальной координате каждой возможной "экранной" точки.
- вместо полутора миллионов вызовов рисования точки - в итоге стало бы одна-две тысячи (от горизонтального разрешения экрана зависит, и от размера области под график) вызовов рисования точки (если мин и макс вертикальные координаты в этой горизонтальной экранной точке совпадают) или вертикального отрезка (если мин и макс вертикальные координаты таки различны).

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

Производительность (быстрота) проги будет во многом зависеть от того, насколько удачно удастся избавиться от тормозных конверсий плавучих значений в целые числа. А то билдер для этого неявно вызывает свою библиотечную функцию __ftol, которая очень тормозит по сравнению с альтернативами (например, с вариантом из библиотечки Агнера Фога).
Проблемы с конверсией плавучки в целое нет у 64разрядных прог (в свежих версиях Билдера), но у Вас-то шестой...



Другой вариант.
Давно уже не работал с этой частью ВинАПИ, поэтому "спроектирую" во многом наугад.
Можно использовать виндовозовские метафайлы. Тем более, что в Билдере над ними есть класс-обёртка (TMetafile), да и канвас умеет эти метафайлы рисовать.
Рисовал бы в метафайл - а затем все масштабирования делал просто пересчётом границ (координат) отрисовываемой области. Границы надо пересчитать так, чтобы в итоге рамка нужной области совпала с границами канваса/пикчербокса, а всё вылезающее за её пределы должно автоматически обрезаться.


Сорри, если сумбурно/непонятно - но у меня третий час ночи

2

VTsaregorodtsev, спасибо за информацию!
Касательно первого предложенного варианта нашел аналогичные решения на просторах интернета.
Создал компонент Image и рисую в нем через Canvas. Далее открываю файл с данными и помещаю их в 2-а динамических массива.
Затем соотношу размеры изображения и количество точек(получается несколько тыс значений на пиксель).
Затем строю график(можно ориентироваться на средние значения, можно на макс и мин).
Позже поробую поэксперементировать с зумом и пересчетом точек в "нормальные" (получится или нет пока не скажу).
Производительность, даже на первый взгляд, превосходит стандартный TChart. При перехода на работу с бинарными файлами предполагаю еще небольшой прирост производительности (в конечном итоге дающий порядка -1 - -2 сек)
Builder6 но другого пока не предполагается)))
2-ой вариант отчасти напоминает первый), а так как я начал решать свою задачу, то оставлю его про запас)
Спасибо за хороший ответ!
P.S. Если есть ссылки на статьи о последнем билдере (например поясняющие чем он хорош и что он умеет), ты прошу скинуть их мне в личку.

0