dCharts Memory leak on client side

Flow
1

Hello folks,

I tried to use dchart(1.7.0) with Refresher(1.2.1.7) addon: refreshing same chart every second…

Any browser tested increses the memory usage…

I tried remove and add a new chart, but no luck, same memory leak.

Somebody knows how to solve/evict it?

Vaadin (7.1.10)

2

No luck until now…:frowning:
In addon page someone resolve this issue, but don´t show how…

3

Any luck on this issue?

4

Hi guys

I guess you know this is general jqplot issue. Here is my solution for dussan’s addon. Idea is to make changes in javascript method (keep references to plots and destroy them). If you create same class in same package in your project you will override default implementation

  1. Create package in your project
    org.dussan.vaadin.dcharts.client.ui
  2. and put there file VDCharts.java (you will find code in dussan’s jar file in maven/ivy local repository) dcharts-widget-1.7.0.jar
  3. now edit method (you will find my implementation in attachment)

private native void showChart(VDCharts c, String id, String dataSeries,
String options, String decimalSeparator, String thousandsSeparator)
4. I don’t remember if you need to recompile widgetset.

Im using charts to draw live market data (refreshing charts even few times in one second). I noticed that this fix helped me a lot but still is not ideal. I noticed that chrome handles live charting nicely (also im opening charts in separate windows (each window in chrome has own process). so closing chart on ui kills windows process and releases some memory.

Before fix I was able to work with application for couple of minutes (now it is not problem at all to work with it all day watching live charts) .

I did same trick to make colours in charts
I made copy of OhlcRenderer.java and replaced every occurance of array to single String object. ie
private String openColor = null; → private String openColor = null;

default inplementation was producing colors in array in css code (something like color:[#FFF]
) and only Firefox was able to handle it correctly.

Sorry for late reply but hope this will help you guys

16817.txt (1.85 KB)