[Отрисовка графиков] Помогите найти решение.

есть ещё highchart http://www.highcharts.com/demo/dynamic-update

Ого, красота однако =)

Есть еще что-то от гугла (google charts).

Оно же течь будет: старые данные из SVG не удаляются. Но вариант интересный. Можно, например, раз в несколько минут перезагружать фрейм фрейм с SVG - тогда память течь не будет.

Но таки вопрос, как эту беду отрисовать - остается в силе.

черт, хотел либератор предложить, а его закрыли...
http://www.freeliberator.com/index.php раньше можно было скачать, согласившись с какими-то условиями, теперь надо заполнять форму..

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

Хмм, а вот webGL интересно, буду гуглить на эту тему.

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

Ну или не post а чего-нить другого.

man websockets.

Ну или по-старинке, в цикле по таймеру.

google visualization api, апи чистый и милый, есть server-side библиотеки под питон и яву для подготовки данных, в динамическое обновление умеет отлично. Минус - vendor lock-in, конечно же, но в остальном - лучшая яваскриптовая либа для графиков.

Лучше было бы на сервере прореживать данные, а на клиенте просто отображать.

Нежелание переносить часть обработки на клиент обыкновенно оплачивается новыми мегабайтами и гигагерцами железа же, ну разве это разумно ?

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

Не надо считать, что у всех халявный скоростной интернет.

Надо постулировать скорость 33кбит/с и опираться в разработке веб-сервисов именно на такую скорость (если только веб-сервис не локальный).

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

> как реализовать динамическое получение данных браузером
ты так и не сходил по моей ссылке? comet же! готовое реешение. есть и другие comet-серверы, не только либератор, про который я писал ранее.

Обана, не заметил что-то вчера =) Сейчас ознакомлюсь.

Дык оно проприетарное что ли? Чо-то лучше в websoket разобраться.

оно было открытым. может, можно как-то старую версию раздобыть. и я тебе говорю, что это не единственный комет-сервер :)

Хе хе, спасибо, comet как раз то что надо =) Нагуглил некий orbit, сейчас в нем разбираюсь.

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

но было это давно и не правда. и либератор прикрыли..

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

Хех, прочитал я про эти технологии, уже говорят, что comet устарел и сейчас нужно использовать SSE или WebSocket =)

Но в любом случае, по причине ниасиляторства зих технологий, переношу тему в http://www.linux.org.ru/forum/job/6671413 :D