Построение графиков java: java — Построить точечный график

0

поделиться

автор: java4africa

Оптимизация графиков Recharts

Рассказывает Иван, Senior Developer в Noveo

Статья будет полезна для веб-разработчиков, использующих React и библиотеку Recharts или другие библиотеки на основе SVG для построения графиков, а также для всех, кто когда-нибудь задумывался об оптимизации производительности своего приложения.

Предыстория

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

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

Recharts

После поиска возможных вариантов и их анализа было принято решение об использовании библиотеки Recharts.

Recharts — это библиотека на основе D3. js, позволяющая строить графики с использованием HTML, SVG и CSS. Главными преимуществами Recharts является то, что она «заточена» под React, и в ней используется компонентный подход, обеспечивающий хорошую модульность. Реализованные на Recharts графики достаточно легко комбинировать и переиспользовать. А также, что очень важно, библиотека позволяет достаточно сильно модифицировать стандартные элементы и переопределять внутренние обработчики.

Библиотека достаточно популярная и имеет большое комьюнити.

Оптимизация графиков

Рассмотрим несколько оптимизаций, использованных в нашем проекте, на примере двух типов графиков.

Первый график — столбиковая диаграмма, Bar chart. В представленной реализации график позволяет выбирать range (участок от-до), и в стейте компонента происходит достаточно много изменений, приводящих к ререндерам.

Первая оптимизация

Выяснилось (c помощью Chrome devtools и React devtools), что ререндер компонента сетки графика и самого графика достаточно дорогой. Он длится порядка 20 мсек на шустрой машине и существенно больше на «медленном» железе.

Сама сетка и оси не меняются в нашем примере при выделении участка. Но именно их ререндер самый дорогой. Встроенной возможности меморизировать их в Recharts нет, и мы решили попробовать другие варианты оптимизаций.

Вынесли стейт в отдельный «дочерний» компонент, где отрисовываются только сами «бары» (для таких целей Recharts предоставляет Customized, где можно реализовать свой компонент, используя svg). Компонент с графиком, осями и сеткой стал при этом stateless и отрисовывался теперь только при первоначальном (initial) рендере. Сами бары находятся теперь внутри дочернего компонента со стейтом и реализованы с помощью элементов svg rect.

От дефолтного тултипа при оптимизации пришлось отказаться, был использован кастомный тултип, который подходил для использования с кастомным графиком на svg rect. В дальнейшем этот тултип также использовался при оптимизации других графиков.

Вторая оптимизация

Отказались от замыканий в пользу data-атрибутов. Recharts использует свой вариант обработчиков для hover, click и других событий на элементах графика, добавляя в обработчик, помимо нативного event, еще и индекс выбранного элемента, дату для выбранной точки и т.д.

На рисунке console.log arguments обработчика.

1 элемент — это данные графика, которые Recharts добавляет в каждый обработчик.

2 — index элемента.

3 — нативный эвент.

Это очень удобно для некоторых задач. Но если ререндеров много и перформанс критичен, то это может оказаться избыточным. В нашем случае было достаточно одного индекса для того, чтобы понять, какой bar выбран, все остальное можно получить из имеющейся даты.

Индекс было решено передавать через data-атрибут. Это позволило использовать один нативный обработчик, который не пересоздается при ререндерах, не использует замыканий и не добавляет лишней информации, только нативный ивент.

Третья оптимизация + детали разработки Line chart (big data)

Рассмотрим другой тип графиков — обычную линейную диаграмму, Line Chart.

Что в нем такого особенного, что пришлось его оптимизировать? Объем данных: выборка за 20+ лет, количество точек в разных кейсах от 10 до 50 тысяч. Помимо этого, в графике нужно было реализовать zoom по колесу мыши и перемещение влево-вправо по оси X.

Подход «в лоб» для этого графика тоже не подошел. Если попробовать использовать Line Chart в дефолтных настройках и отрисовать 20k точек, получится что-то страшное. Первым делом нужно отключить встроенную анимацию и отображение точек

После этого график выглядит уже смотрибельно и не грузится покадрово при первичной отрисовке. Но как нам добиться зума и перемещения «окна просмотра»?

Recharts построен на базе библиотеки D3.js, где есть такое понятие, как domain (область). По сути это тот диапазон значений, который будет отображаться на графике. То есть если мы установим domain для оси Х: [1047686400, 1071446400]  (unix timestamp), то получим такой вид:

Это как раз то, что нам нужно: будем управлять domain при прокрутке колеса мыши и получим zoom. Но тут есть нюанс: мы не можем просто увеличивать или уменьшать размер области пропорционально шагу прокрутки колеса мыши — нам нужна
«точка отсчета». Если мы хотим приблизить участок в конце таймлайна и ставим туда курсор, то мы ожидаем, что зум будет именно в этой области, а не относительно центра оси.

Реализация зума в коде выглядела приблизительно так:

Для перемещения влево/вправо использовался похожий принцип, только вместо изменения размеров domain смещается влево/вправо пропорционально перемещению курсора при зажатой клавише мыши.

В целом график в таком виде уже был в рабочем состоянии, но перформанс проседал на «медленном» железе именно при ресайзе и перемещении окна графика (~9 fps):

Мы решили попробовать нарисовать линию самостоятельно с помощью Customized-компонента, как и в предыдущем примере. При каждом изменении domain запускается расчет нового svg-path.

Здесь намеренно используется for, на данный момент он все еще значительно быстрее функциональных аналогов forEach, map, reduce, и т. д. (смотрите статью). Кажется, что для десятков тысяч точек это слишком дорогая операция, но на практике это достаточно быстро. В production mode при таком подходе fps не падает ниже 27-30 в моменты ресайза, при среднем значении 55-60 (до оптимизации fps 8-10).

Но, к сожалению, при таком подходе нам снова приходится отказаться от встроенных тултипов и указателя выбранной точки на графике. Главная сложность заключается именно в расчете позиции точки указателя на графике. Нам нужно по позиции курсора определить ближайшую точку и «примагнититься» к ней. В JavaScript нет built-in инструментов для проведения hit-test, мы не можем получить координаты пересечения двух отрисованных линий (иначе можно было бы схитрить — нарисовать нормаль из позиции курсора, но примагничивания к точке мы бы не получили).

Нам остается аналитический расчет и поиск ближайшей точки самостоятельно.
Для начала нужно вычислить координаты курсора относительно холста и посчитать соответствующее значение по оси X, исходя из текущего домена (к счастью, у нас линейный scale и это обычная пропорция). Это будет текущее значение по оси X для точки курсора. А дальше начинается самое интересное — поиск в массиве ближайшего значения точки, к которой мы собираемся «примагничиваться».

Все было бы достаточно просто для небольших массивов (до 1к элементов). Но при количестве точек до 50k (кроме того, была задача на аналогичный график сразу с 2 линиями) хотелось выбрать что-то оптимальнее простого перебора. И такой алгоритм нашелся.

Тут важно заметить, что мы имеем дело с уже отсортированным массивом — значения по оси x всегда возрастают.

Бинарный поиск — самый быстрый поиск для отсортированных списков. Не очень часто применяемый во frontend-разработке алгоритм оказался для этой задачи оптимальным решением.

Максимальное количество итераций log2N, то есть для 50k элементов всего 16 итераций.

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

Точку на графике реализовали также через Customized-компонент и svg circle, а направляющие линии — через обычный div с рамкой с 1 стороны.

Вертикальная направляющая линия:

Тултип и точка на графике (ну и плюс направляющие) в итоге работают достаточно шустро, как и ресайз области и drag окна по оси X.

Замечание

Recharts — хорошая библиотека. После прочтения этой статьи может сложиться впечатление, что все приходится делать на очень низком уровне и «руками». Это не так, и в большинстве случаев нам с лихвой хватало функциональности библиотеки даже для сложных графиков. Но в условиях жестких требований к производительности, большого количества сложных ререндеров или при работе с большими массивами данных может потребоваться кастомизация.

И на наш взгляд, прекрасно, что Recharts дает такую возможность «допилить напильником» в узких местах.

Достигнутый результат

Немного статистики по производительности после оптимизаций первого графика:

Замедляем CPU в 6 раз для наглядности (в Chrome devTools) и сравниваем.

До — длительность таски при ререндере — 162 мс (легко посчитать — около 6 fps):

После — длительность 31 мс (32 fps, достойно, учитывая, что CPU замедлен x6):

И на общем графике — слева до, справа после оптимизации:

Разница в загрузке CPU и длине цикла отрисовки внушительная.

Статистика после оптимизаций второго графика

Общая шкала ререндеров до и после оптимизации (слева до):

Попробуйте сами.

Заключение

Оптимизации — это здорово, но они требуют достаточно больших временных затрат. Стоит изначально тщательно подойти к выбору инструментов, библиотек, которые будут использоваться.

Далее речь пойдет в первую очередь о библиотеках, подходящих для использования в проектах на React. Если в вашем проекте используются преимущественно «стандартные» типы графиков со средним размером данных и умеренными требованиями к перформансу, Recharts — ваш выбор.

Если кастомизаций слишком много и каждый второй график вам придется «собирать с нуля», возможно, стоит посмотреть на библиотеки, дающие больше свободы и более низкоуровневые компоненты. Например, VX.

Когда инструмент выбран правильно, но оптимизировать все таки нужно — сначала стоит разобраться в причинах проблем (console.time и chrome devTools + react devTools вам в помощь).

И, если времени на исследование достаточно, — не бойтесь пробовать. Возможно, для какого-то специфического случая вы найдете более оптимальное решение проблемы.

Экспериментируйте, и все получится!

plot. Существуют ли какие-нибудь приличные бесплатные библиотеки для построения графиков данных Java?

Спросил 14 лет, 2 месяца назад

Изменено 3 года назад

Просмотрено 32k раз

45

Новинка! Сохраняйте вопросы или ответы и организуйте свой любимый контент.
Узнать больше.

В недавнем проекте Java нам понадобилась бесплатная утилита для построения графиков данных в реальном времени на основе Java. После долгих поисков мы нашли этот инструмент под названием Scientific Graphics Toolkit или SGT от NOAA. Это казалось довольно надежным, но мы обнаружили, что это было не очень настраиваемым. Или, по крайней мере, недостаточно настраиваемый для удовлетворения наших потребностей. В итоге мы очень глубоко копались в коде Java, перепроектировали код и изменили его полностью, чтобы инструмент построения графиков выглядел и действовал так, как мы хотели, чтобы он выглядел и действовал. Конечно, это убило все шансы на будущие обновления от NOAA.

Итак, какие бесплатные или дешевые инструменты или библиотеки для построения графиков на основе Java вы используете?

Последующие действия: Спасибо за предложения JFreeChart. Я проверил их веб-сайт, и он выглядит как очень хорошая утилита для построения графиков и графиков данных. Я должен был четко указать в своем первоначальном вопросе, что я специально искал данные в реальном времени. Я исправил свой вопрос выше, чтобы прояснить этот момент. Однако похоже, что поддержка JFreeChart для оперативных данных в лучшем случае незначительна. Любые другие предложения там?

• Java
• сюжет
• конфигурация

1

Мне удалось успешно использовать JFreeChart в нескольких проектах. Это очень настраиваемый . JFreeChart имеет открытый исходный код, но они взимают плату за руководство для разработчиков. Если вы делаете что-то простое, примера кода, вероятно, будет достаточно. В противном случае 50 долларов за руководство разработчика — довольно выгодная сделка.

Что касается данных «в реальном времени», я также использовал JFreeChart для таких приложений. К сожалению, мне пришлось создать несколько пользовательских моделей данных с соответствующими механизмами синхронизации, чтобы избежать условий гонки. Тем не менее, это было не так уж сложно, и JFreeChart по-прежнему был бы моим первым выбором. Однако, как следует из часто задаваемых вопросов, JFreeChart может не дать вам наилучшей производительности, если это вызывает серьезную озабоченность.

1

Я только что столкнулся с похожей проблемой (отображение быстро обновляемых данных для инженерных целей), и я использую JChart2D. Он довольно минималистичный и имеет несколько особенностей, но кажется довольно быстрым: я запускаю тест скорости, добавляя 2331 точку в секунду (333×7 трасс) к ленточной диаграмме и используя 1% ЦП на моем 3-ГГц Pentium 4.

1

Live Graph поддерживает рендеринг в реальном времени.

Я использую GRAL для построения графиков в реальном времени. Это библиотека Java LGPL. Хотя он не такой мощный, как JFreeChart, у него более удобный API. Я получил сюжет и работает в очень короткие сроки. Они также предоставляют пример построения графиков в реальном времени.

Я нашел этот вопрос, когда искал в Google графические библиотеки с открытым исходным кодом для Java. Я не был очень доволен ответами, размещенными здесь, поэтому я провел дополнительное исследование по этому вопросу. Хотя этот вопрос был опубликован еще в 2008 году, он все еще может быть кому-то интересен.

Вот список инструментов для построения диаграмм и отчетов с открытым исходным кодом на Java.

Чтобы обновить график, укажите URL-адрес файла данных, а затем добавьте &filePollUpdates=1&tail=100 . См. пример на http://autoplot.org/cookbook#Loading_Data

Waterloo Scientific Graphics — это новый проект LGPL. Объекты данных доступны для наблюдения и могут быть обновлены в сценарии построения графиков в реальном времени. Подробнее см. http://waterloo.sourceforge.net/

Несколько скриншотов:

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

Я использовал JFreeChart (http://www.jfree.org/jfreechart/) в предыдущем проекте. У него есть несколько очень хороших встроенных возможностей, а дизайн был НАМНОГО расширяемым, поэтому вы всегда можете развернуть свое собственное расширение позже, если вам понадобится какая-то пользовательская аннотация диаграммы или вы хотите, чтобы ось отображалась по-другому, или что-то еще. Это определенно стоит проверить.

Проверьте JViews ILOG — там много всего, и что-то может подойти вам. Все они чрезвычайно настраиваемые и довольно быстрые. Хотя и не бесплатно.

Я использовал JFreeChart в довольно сложном приложении, которое требовало визуализации потоков данных и вычислений на основе данных. Мы реализовали возможность визуального редактирования графиков данных с помощью мыши и имели очень большой набор точек данных. JFreeChart справился с этим очень хорошо.

К сожалению, я застрял на версии 0.7, но последняя версия намного лучше, когда дело доходит до ясности API. Сообщество очень полезно, и разработчики также отвечают на письма.

Если вы делаете веб-приложение и не хотите возиться с библиотеками, вы можете проверить Google Chart API. Сам не использовал его, но я начал несколько тестов, которые были очень многообещающими.

Для построения графиков в реальном времени вы можете использовать QN Plot, JOpenChart или его ответвление Openchart2.

JHandles — альтернативный графический пакет для Octave (математический пакет). Это, вероятно, стоит изучить, но, будучи специфичным для Octave, может не иметь того, что вам нужно.

-Адам

PtPlot может быть хорошим выбором. Ранее назывался Птолемеем.

jcckit может обрабатывать графики в реальном времени. Это медведь, чтобы использовать все же.

Я разветвил его и сделал очень простую оболочку вокруг него для построения графиков не в реальном времени. Базовый сложный интерфейс также можно использовать напрямую.

https://bitbucket.org/hughperkins/easyjcckit

Вы можете проверить JMathPlot

0

Ошибка Java при вызове команды PLOT и использовании графики. — Ответы MATLAB

У меня возникает следующая ошибка, выдаваемая MATLAB R2015a, когда я пытаюсь что-то построить:

javax.media.opengl.GLException: Profile GL_DEFAULT недоступен на X11GraphicsDevice [тип .x11, подключение: 65.0, unitID 0, дескриптор 0x0, владелец false, ResourceToolkitLock[obj 0xe0ae46a, isOwner false, <6d19f259, 4275e904>[count 0, qsz 0, owner ]]], но: []

в javax.media.opengl.GLProfile.get(GLProfile.java:962)

в javax.media.opengl .GLProfile.getDefault(GLProfile.java:693)

в javax.media.opengl. GLCapabilities.(GLCapabilities.java:84)

в com.mathworks.hg.peer.JavaSceneServerPeer.getCaps(JavaSceneServerPeer.java :169)

в com.mathworks.hg.peer.JavaSceneServerPeer.doCreateCanvas(JavaSceneServerPeer.java:704)

в com.mathworks.hg.peer.JavaSceneServerPeer.access$200(JavaSceneServerPeer.java:49)

в com.mathworks.hg.peer.JavaSceneServerPeer$2.run(JavaSceneServerPeer.java:683)

в java.awt. event.InvocationEvent.dispatch(неизвестный источник)

в java.awt.EventQueue.dispatchEventImpl(неизвестный источник)

в java.awt.EventQueue.access$200(неизвестный источник)

в java.awt.EventQueue$3.run( Неизвестный источник)

в java.awt.EventQueue$3.run(Неизвестный источник)

в java.security.AccessController.doPrivileged (собственный метод)

в java.security.ProtectionDomain$1.doIntersectionPrivilege (неизвестный источник)

в java.awt.EventQueue.dispatchEvent (неизвестный источник)

в java.awt. EventDispatchThread. pumpOneEventForFilters(неизвестный источник)

в java.awt.EventDispatchThread.pumpEventsForFilter(неизвестный источник)

в java.awt.EventDispatchThread.pumpEventsForHierarchy(неизвестный источник)

в java.awt.Eventspatch.EventsForFilter(неизвестный источник)0005

в java.awt.EventDispatchThread.pumpEvents(неизвестный источник)

в java.awt.EventDispatchThread.run(неизвестный источник)

javax.media.opengl.GLException: профиль GL_DEFAULT недоступен на X11GraphicsDevice[тип .x11, соединение: 65.0, unitID 0, дескриптор 0x0, владелец false, ResourceToolkitLock[obj 0xe0ae46a, isOwner false, <6d19f259, 4275e904>[count 0, qsz 0, owner ]]]], но: []

в javax. media.opengl.GLProfile.get(GLProfile.java:962)

в javax.media.opengl.GLProfile.getDefault(GLProfile.java:693)

в javax.media.opengl.GLCapabilities.(GLCapabilities.java:84)

в com.mathworks.hg.peer. JavaSceneServerPeer.getCaps(JavaSceneServerPeer.java:169)

по адресу com. mathworks.hg.peer.JavaSceneServerPeer.doCreateCanvas(JavaSceneServerPeer.java:704)

по адресу com.mathworks.hg.peerSceneServerPeerPeer(JavaSceneServer20.0.0. :49)

в com.mathworks.hg.peer.JavaSceneServerPeer$2.run(JavaSceneServerPeer.java:683)

в java.awt.event.InvocationEvent.dispatch(неизвестный источник)

в java.awt.EventQueue.dispatchEventImpl(неизвестный источник)

в java.awt.EventQueue.access$200(неизвестный источник)

в java. awt.EventQueue$3.run(неизвестный источник)

в java.awt.EventQueue$3.run(неизвестный источник)

в java.security.AccessController.doPrivileged(собственный метод)

в java.security.ProtectionDomain$1.doIntersectionPrivilege (Неизвестный источник)

в java.awt.EventQueue.dispatchEvent (Неизвестный источник)

на java.awt.eventdispatchthread.pumponeeventforfilters (неизвестный источник)

на java.awt.eventdispatchthread.pumpeventsforfilter (неизвестный источник)

at java. awt.eventdispatchthread.pumpevEvEvEvEvERHERHYERARCHY (UNTSKERSISPTARTSTARTSTARTSTARTSTARTSTARTSTARIPTARCHY. .pumpEvents(неизвестный источник)

в java.awt.EventDispatchThread.pumpEvents(неизвестный источник)

в java.awt.EventDispatchThread.run(неизвестный источник)

javax.media.opengl.GLException: профиль GL_DEFAULT недоступен на X11GraphicsDevice[тип .x11, соединение: 65.0, unitID 0, дескриптор 0x0, владелец false, ResourceToolkitLock[obj 0xe0ae46a, isOwner false, <6d19f259, 4275e904>[count 0, qsz 0, owner ]]], но: []

в javax.media.opengl.GLProfile.get(GLProfile.java:962)

в javax.media.opengl .GLProfile.getDefault(GLProfile.java:693)

в javax.media.opengl.GLCapabilities.(GLCapabilities.java:84)

в com.mathworks.hg.peer.JavaSceneServerPeer.getCaps(JavaSceneServerPeer.java :169)

в com.mathworks.hg.peer.JavaSceneServerPeer.doCreateCanvas(JavaSceneServerPeer.java:704)

в com.mathworks.hg.peer.JavaSceneServerPeer. access$200(JavaSceneServerPeer.java:49)

в com.mathworks.hg.peer.JavaSceneServerPeer$2.run(JavaSceneServerPeer.java:683)

в java.awt. event.InvocationEvent.dispatch(неизвестный источник)

в java.awt.EventQueue.dispatchEventImpl(неизвестный источник)

в java.awt.EventQueue.access$200(неизвестный источник)

в java.awt.EventQueue$3.run( Неизвестный источник)

в java.awt.EventQueue$3.run(Неизвестный источник)

в java.security.AccessController.doPrivileged (собственный метод)

в java.security.ProtectionDomain$1.doIntersectionPrivilege (неизвестный источник)

в java.awt.EventQueue.dispatchEvent (неизвестный источник)

в java.awt. EventDispatchThread.pumpOneEventForFilters(неизвестный источник)

в java.awt.EventDispatchThread.pumpEventsForFilter(неизвестный источник)

в java.awt.EventDispatchThread.pumpEventsForHierarchy(неизвестный источник)

в java.awt.Eventspatch.EventsForFilter(неизвестный источник)0005

в java. awt.EventDispatchThread.pumpEvents(неизвестный источник)

в java.awt.EventDispatchThread.run(неизвестный источник)

Как это можно исправить. Это началось случайно, так как я не вносил никаких изменений в систему.

Информация о системе Xubuntu 12.04 64-битный MATLAB 2015a Версия Java «1.6.0_35» Среда выполнения OpenJDK (IcedTea6 1.13.7) (6b35-1.13.7-1ubuntu0.12.04.2) OpenJDK 64-битный сервер VM (сборка 01,25-b смешанный режим)

Графический дигитайзер