Ускорение отрисовки графика

[Penumbra]

Доброго времени суток
Я строю график по данным из БД.
в БД сохранены 222200 записей ( напряжение с шагом 2 секунды)
если я строю график за промежуток в пару часов график прорисовывается довольно быстро, но если я запрашиваю данные за период в 5-6 суток то график строится 2-3 минуты!
может можно как-то увеличить скорость построения графика?

[alibek]

Нет смысла рисовать с большим разрешением, чем экранный пиксель.
Определить разрешение экранного пиксела и рисовать с вычисленным шагом.

[Penumbra]

это я уже понял, вот осталась проблема как из бд правильно вытащить данные, т.е. ширина пикчурбокса 1000 пикселей, в БД 222к записей и как из 222000 записей усреднить/сгладить/выбрать 1000 записей?

[Хакер]

При выборке каждой записи поставить в соответствие ей числовой показатель, округлить его до некоторой степени грубости так, чтобы после группировки по округлённому числу записи собрались по 222 штуки (на пиксель). (А не по 1000 записей, как ты спросил, ибо это не то, что надо).

В группировке брать AVERAGE() и в растре графика рисовать одну точку, либо MIN() и MAX() и в растре графика заполнять все пиксели столбика от минимума до максимума.

Обычно числовой показатель есть и так — это та величина, которая откладывается в графике по оси X. Это может быть время или иногда порядковый номер записи.

Что касается самого рисования, то вместо попиксельных обращений, можно создать необходимый растр в памяти, а потом разом его перенести (SetDIBitsToDevice) на дисплей.

[Хакер]

Кстати, когда записей 222 000, а пикселей по горизонтали всего 1000 — это очень хороший случай. Лёгкий, потому что на каждый пиксель приходится 222 записи. Совершенно другое дело, когда по горизонтали 1000 пикселей, а в базе 1700 записей. Получается 1.7 записей на пиксель. Так сколько же брать реально записей для прорисовки графика?

Возьмёшь 1 запись на 1 пиксель, получишь, что влезет только 1000 записей, 700 не влезет вообще.
Возьмёшь 2 записи на 1 пиксель, получишь, что будет использовано только 850 пикселей горизонтального пространства графика, 15% оси использовано не будет.

Какой выход?

Выхода два:

1. Можно использовать алгоритм Брезенхема, воспринимая его не как алгоритм рисования прямых линий на растре, а как алгоритм распределения N яблок по M корзинам (где N не делится без остатка на M, как, например, 1700 не делится без остатка на 1700). В этом случае у графика получится, что у графика не постоянный, а переменный показатель «количество записей на столбец графика».
2. Применять сглаживание/интерполяцию, когда ордината определяется не значением одной записи, а складывается из значений соседних записей, к величинам которых применены весовые коэффициенты, пропорциональные тому, насколько идеальная (гипотетическая) запись удалена от двух реальных соседних.
   Например, когда 300 записей нужно отобразить на 200px графике (в ширину), то на пиксель приходится 1.5 записи, что нереально. Для первого пикселя мы не можем взять полторатую (sic!) запись, потому что есть только первая и вторая. Поэтому мы складываем значения первой и второй записи, применяя коэффициент 0.5 и 0.5 к каждой. Вторая точка приходится на 1.5×2=3 — третью запись. Поэтому просто берётся значение третьей записи, без соседних записей и без весовых коэффициентов. А дальше 4.5-ая запись, но такой нет, и значит берётся среднее между значением 4-ой и 5-ой. Будь у нас 1.7 записей на пиксель, то для первого пикселя мы бы брали первую и вторую запись, но весовые коэффициенты были бы 0.3 и 0.7. Для второго пикселя весовые коэффициенты были бы 0.6 и 0.4.