Написание собственного графика.

[Bepec]

Приветствую заглянувших.

Появилась необходимость в отрисовке графиков.

Цель: Написать легкий компонент для отображения и масштабирования графиков и поднатаскать себя в области графического отображения.

Проблема: не могу найти литературу и продумать архитектуру. (т.е. считай знание геометрии за 9 классов есть, не больше )

Собственно мне представляется следующая архитектура:
1) класс - полотно. Отображает точечки, рисует оси координат.
2) класс - хранилище данных. Отдаёт данные полотну (или нескольким) посредством сигналов.
3) прокси класс - масштабирующий компонент. Принимает данные от хранилища данных, преобразовывает, отдаёт полотну. Должен как то стыковаться с полотном для получения действий пользователя.

PS посоветуйте литературу по графикам - усреднению и прочему.
PPS ну и на огрехи в архитектуре поругайте

[m_ax]

Как то писал подобный велосипед) LightPlot2D - вот здесь обсуждение http://www.prog.org.ru/topic_10208_90.html

Есть сама библиотека lightplot2d здесь https://code.google.com/p/lightplot2d/

И есть отдельно под неё написанный виджет со всеми диалогами и т.д.. (приаттачил пару скриншотов)

Но это уже давно мёртвый проект и сейчас понимаю, как писать не надо было)

 

[m_ax]

Приатачиваю сам Plotter (требует lightplot2d)

[Bepec]

Ммм... Эт конечно круто Но мне б свои навыки прокачать в создании графических велосипедов Был бы нужен готовый - использовал бы QWT. ^.^

PS посмотрю код, мож чего надёргаю. Мне теории нехватает.

PPS посмотрел ваш плот - интересно. Но увы. У меня примерно 40 тысяч на 60 тысяч график должен быть по осям. Собственно велосипеды других, в том числе и ваш под это не особо подойдут. Тут нужен свой, оптимизированный. 

[Igors]

Цель: Написать легкий компонент для отображения и масштабирования графиков и поднатаскать себя в области графического отображения.

На мой взгляд такая цель/постановка неудачна. Рисование руками саедется к множеству вызовов небольшого числа ф-ций типа MoveTo/LineTo, т.е. рутинной работе - право, задействовать готовую либу здесь гораздо более уместно (даже для такого закоренелого велосипедиста как я  )

А вот написать компонент "график мини-модулятор" может и есть смысл, в моих задачах он часто нужен. Если интересно, расскажу больше

Edit:

PPS посмотрел ваш плот - интересно. Но увы. У меня примерно 40 тысяч на 60 тысяч график должен быть по осям. Собственно велосипеды других, в том числе и ваш под это не особо подойдут. Тут нужен свой, оптимизированный. 

Не Вы ли неоднократно упоминали про богатырскую силу model-view подхода? Ну так примените. Скармливайте стандартному графику не оригинальные точки (которых слишком много) а их упрощенное представление, на то и модель

[Bepec]

Собственно в том и проблема
Велосипеды идут в смысле - дайте точек, а мы нарисуем.

Мне же надо - дайте точек, мы их оприходует, оптимизируем, отмаштабируем и покажем. Тот же Qwt не справляется с задачей отрисовки. Потому я и хочу изучить эту сторону программирования. Графики, оптимизация, усреднения. Вот только как обычно литературы не найду.

PS если вы не успели или не читали мою архитектуру, то она подозрительно похожа на model - view.

[m_ax]

PPS посмотрел ваш плот - интересно. Но увы. У меня примерно 40 тысяч на 60 тысяч график должен быть по осям.

Что значит 40 на 60 тысяч график? График (кривая) представляется вектором, элементы которого двумерная точка (QPointF, например) - значение x и y, соответственно.

Сейчас ради интереса зарядил две кривых по 100 тысяч точек в каждой. На моём древнем железе особых тормозов не обнаружил..

[m_ax]

Да, архитектура Model/View для этого дела - очень хорошо.

[Bepec]

Ну так влегкую чуть поменял ваш пример - у меня полграфика черные и думает при ресайзе эм... секунды 3-5. ( i5 )

Мож я что-т не так настроил? Не скинете код  в личку, дабы темку не сорить.

[m_ax]

Скинул..
Пол графика чёрные - это надо сетку по оси x по разреженней сделать, скорее всего.
Тормоза все - из-за самой отрисовки точек. В архитектуре MVC можно задавать делегату, например, максимальное число точек по "x", н.т. минимальное и максимальное разрешение, а вьюха, основываясь на этих данных делегата, отображала бы уже просеянные данные..
     

[Bepec]

Получил, смотрю.

Собственно часть вашего проекта я слямзю и буду разбираться потихоньку
Часть отображения меня привлекла. Облечь это в model-view и может что-нить да выйдет полезное для меня )

[Bepec]

Up. Никто литературки не посоветует?

[Bepec]

Up.

Добрался до ещё одной проблемы, которая встречается и в вашей библиотеке. При рисовании графика по точкам, если следующая точка не входит в область рисования, то весь отрезок пропадает.

Я так понимаю, это нормальное поведение, вот только оно мне не нравится Нет никаких мыслей по этому поводу?

PS подумал немного - нормальное поведение для точечного графика. Возможно нужно будет добавить несколько вариантов отдачи данных.

PPS что быстрее - drawPoint, drawPolygon или drawPolyline?

[Igors]

Добрался до ещё одной проблемы, которая встречается и в вашей библиотеке. При рисовании графика по точкам, если следующая точка не входит в область рисования, то весь отрезок пропадает.

Я так понимаю, это нормальное поведение, вот только оно мне не нравится Нет никаких мыслей по этому поводу?

Просто рисовать +1 точку слева и справа, а clip сам отсечет. Из той же оперы: левая часть буквы (напр 30%) красным цветом, правая белым.  Как нарисовать?

[Bepec]

Так у меня свой clip

Собственно реализовано простейшее model-view.
View запрашивает данные и передаёт размер сцены, модель возвращает точки.

Собственно вопрос который возник - точки разделены большими промежутками. Модель содержит данные об имеющихся точках, которые разнесены где то на 100 тысяч по x/y. Если рисовать всё - умрёт программа ну и вопрос - на максимальном удалении видна огибающая - это красиво и понятно.

Начинаешь приближать допустим до 3 точек - получается хорошая огибающая, оканчивающаяся на 1 и 3 точке - терпимо.
Приближаешь, желая увидеть что-то в промежутке между точками - а там пустота, ибо уже ни одна точка в этот промежуток не попадает.

Моя мысль - сделать режим, который по точкам строит уже огибающие и возвращает необходимые куски огибающих. Это затратно.

Какие предложения есть у вас? 

to Igors: ответ содержится в вопроса, clip отрежет необходимые %.