[Arlleex 187]

Билдеровский teechart, ИМХО, какой-то кривоватый. Не, я в том плане, что для многих задач он, может, и годится, но есть у него и свои приколдесы. Например, при отображении графиков в реальном времени у него могут быть проблемы с буферизацией. Он довольно сильно грузит процесс формы, поэтому здесь лучше рассмотреть что-то около OpenGL (непосредственно его или компонент на его основе). К сожалению, я не могу сказать, что там в основе teechart, но, скорее всего, обычное рисование на канве.

[Xenia 45]

7 часов назад, jcxz сказал:

А Вам реально нужны 64-разрядные приложения? Зачем, если не секрет?

Чтобы со всей памятью работать (у меня 32 ГБ). Матрицы большого размера нужны, в 4 ГБ памяти не помещаются.

[jcxz 241]

5 часов назад, Arlleex сказал:

обычное рисование на канве.

К слову: Когда-то давно писал очередной осциллограф (реалтайм) в одной из программ. Рисование у меня там шло через WinAPI максимально оптимально - в памяти несколько битовых плоскостей (плоскость с нарисованными фиксированными элементами экрана: шкалы, сетка и т.п.; плоскость с рисуемыми графиками (не целиком перерисовываемая каждый раз, а перерисовывался только узкий вертикальный столбик, как если бы считать плоскость свёрнутой в цилиндр и рисование шло на нём); плоскость с перемещаемыми наложенными поверх графиков картинками и т.д.). Потом все эти плоскости объединялись в результирующую плоскость с помощью семейства BitBlt-функций, результирующая плоскость - уже в видео-ОЗУ.

Вобщем-то - скорости вполне хватало, всё работало гладко. Просто ради интереса решил перевести это на работу через DirectDraw API (2D который). И заметил, что разницы в скорости между WinAPI-ным и DirectDraw-API вариантами нет!  Совсем! Даже в самых худших условиях (полная перерисовка с максимальным количеством графиков, состоящих из максимального числа отрезков (осциллограмма белого шума), окно осц. - на весь экран). Тогда попробовал просто в системе выключить поддержку DirectDraw. Естественно вариант с работой через DirectDraw вообще перестал работать, а вариант работающий через WinAPI работать не перестал, но скорость его упала в несколько раз.

Из чего я сделал вывод, что графические функции WinAPI внутри вызывают DirectDraw. Когда есть такая возможность. 

Так что штатная WinAPI-шная PolyPolyline() - возможно и есть самый быстрый способ отрисовки графика. Ничего сложнее придумывать не надо.

[alexunder 4]

On 12/23/2021 at 8:31 PM, Xenia said:

Но вопрос у меня другой - как под VS разные графики и диаграммы рисовать, которые на Bulder 6.0 делались в пол тычка мышкой?

Под C# (winforms, wpf) есть очень неплохой ScottPlot, бесплатный и с тучей разных вариантов графиков. Недавно делал на нем подобие овцелографа, очень удобный компонент, работает быстро.

[Xenia 45]

24.12.2021 в 08:36, Arlleex сказал:

Билдеровский teechart, ИМХО, какой-то кривоватый. Не, я в том плане, что для многих задач он, может, и годится, но есть у него и свои приколдесы. Например, при отображении графиков в реальном времени у него могут быть проблемы с буферизацией. Он довольно сильно грузит процесс формы, поэтому здесь лучше рассмотреть что-то около OpenGL (непосредственно его или компонент на его основе). К сожалению, я не могу сказать, что там в основе teechart, но, скорее всего, обычное рисование на канве.

Родной билдеровский teechart немного кривоват, но поверх него на тот же Buillder легко ставится более богатая версия teechart'a - 8-ая или выше (у меня 8.03, на которую есть исходники).

В реальном времени рисовать графики teechart не годится, т.к. он при каждом обновлении станет перерисовывать всю кривую заново, а то и вместе с осями :).

А вот OpenGL - ужасная гадость :), т.к. рисует медленно из-за слишком сложной реализации, а интерефейс крайне неудобный. Тогда как я речь веду не о примитивах, а о законченных решениях, примером которого может быть функция plot() в Matlab. Поиметь бы такую же функцию в MSVC, и больше ничего для счастья не надо :).

[alexunder 4]

41 minutes ago, Xenia said:

примером которого может быть функция plot() в Matlab. Поиметь бы такую же функцию в MSVC, и больше ничего для счастья не надо :).

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

[Xenia 45]

1 час назад, alexunder сказал:

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

Так то C#. С поддержкой гигантского Фреймворка можно не то что графики, а и вприсядку плясать :). Такой дорогой ценой график мне не нужен.

[alexunder 4]

24 minutes ago, Xenia said:

Так то C#. С поддержкой гигантского Фреймворка можно не то что графики, а и вприсядку плясать :). Такой дорогой ценой график мне не нужен.

Дорогой ценой? В вашей Windows не установлен .Net? Если так, то это должна быть Windows 2000 или XP.

А под C++ в MSVS разве есть приличные компоненты двумерных графиков? Когда-то давно в MFC применял NTGraph, но это такие костыли...

[Xenia 45]

17 минут назад, alexunder сказал:

Дорогой ценой? В вашей Windows не установлен .Net? Если так, то это должна быть Windows 2000 или XP.

А под C++ в MSVS разве есть приличные компоненты двумерных графиков? Когда-то давно в MFC применял NTGraph, но это такие костыли...

У меня Windows 7 SP1, но Framework 3.5 по умолчанию на ней не установлен. Кроме того, я совершенно не желаю привязываться к Фреймворку, а тем более переходить на другой язык ради графика.

[alexunder 4]

4 minutes ago, Xenia said:

У меня Windows 7 SP1, но Framework 3.5 по умолчанию на ней не установлен. Кроме того, я совершенно не желаю привязываться к Фреймворку, а тем более переходить на другой язык ради графика.

В чем тогда рисуете, если не секрет?

[Xenia 45]

22 минуты назад, alexunder сказал:

В чем тогда рисуете, если не секрет?

На Borland C/C++ 6.0 пока рисую (с помощью TeeChart), а на MSVC приходится без рисунков обходиться.

Впрочем, в одном из проектов рисовала на OWLNext (это дальнейшее развитие OWL из Borland C/C++ 5.02), но там довольно примитивные функции - готовых графиков и диаграмм нет.

Отсюда и моё любопытство к этой теме - вдруг кто-то уже нашел достойную замену Билдеру.

[_pv 78]

2 hours ago, alexunder said:

А под C++ в MSVS разве есть приличные компоненты двумерных графиков? Когда-то давно в MFC применял NTGraph, но это такие костыли...

всегда хватало gnuplot'a

 

[alexunder 4]

7 hours ago, _pv said:

всегда хватало gnuplot'a

Так это вроде и не библиотека компонентов, которые в форму можно вставить, а отдельное приложение.

[jcxz 241]

12 часов назад, Xenia сказал:

Отсюда и моё любопытство к этой теме - вдруг кто-то уже нашел достойную замену Билдеру.

Любое универсальное решение (реализующее сразу все возможные плюшки нужные в разных применениях), будет громоздким и тормозным. А любое шустрое и лёгкое решение - наверняка не будет уметь какие-то хитрые возможности, нужные в <1% задач.

Вот например моё осциллографирование в текущей задаче умеет качать пучок осциллограмм (до нескольких десятков источников) с одного канала (TCP-сокет), накапливать это в одном большом кольцевом буфере. Каждый источник осц. - имеет свой формат (разрядность, знак, плавучка/fixed_point). К этому кольцевому буферу могут быть подключены от 1 до N независимых окон осциллографирования, до 8-и лучей в каждом. В каждом окне можно включать/выключать запрашиваемые источники осц. (от исходного устройства), переводить окно в offline (с сохранением возможности просмотра и прокрутки/масштабирования захваченных графиков; защёлкнутые осц. "замораживаются" в главном кольцевом буфере, не удаляясь из него пока не будет закрыто окно или переведено в online). И ещё многое другое умеет. Всё это - в реалтайм, на не очень большом буфере в устройстве (и чтобы этот буфер не успевал переполняться при манипуляциях с окнами осц. на ПК и при максимальном потоке осциллограмм).

Сомневаюсь, что какое-то готовое решение всё это умеет.... И при этом запускается моя прога - доли секунды, а не как большинство современного ПО. 

[_pv 78]

10 hours ago, alexunder said:

Так это вроде и не библиотека компонентов, которые в форму можно вставить, а отдельное приложение.

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

но можно и гнуплот-терминал поменять, попросить его нарисовать в память, отдать картинку и отобразить её самому потом куда надо. gnuplot так встроен в octave.

и не без разницы ли притащить .dll и звать из неё функции plot("sin(x)"); или притащить .exe, открыть через popen и отправлять ему команды и читать обратно картинку через fwrite (gp, "plot sin(x)"); / fread?

 

ещё как-то давно mathGL использовал, выглядит неплохо, особенно если что-нибудь сложнее одномерных графиков надо

http://mathgl.sourceforge.net/doc_ru/Pictures.html