Community
Participate
Working Groups
Build Identifier: 20100617-1415 I've just been evaluating whether my team can make use of the BIRT charting libraries and whilst the functionality provided by org.eclipse.birt.chart looks good, my tests show the performance isn't close to being good enough for us. Here are my initial results: Time taken to paint the chart the first time: ~2100ms Time taken to repaint the chart: ~1600ms We're looking for something in < 100ms and wouldn't use BIRT until it could meet that target (hence I've raised this as a major issue). Some more details: * Test case based on the SwtChartViewerSelector.java in org.eclipse.birt.chart.examples.core_2.6.0.v20100607.jar (see attachment) * Stacked area graph * 1 x-axis series of 300 doubles (0 -> 30, incrementing by 0.1 each time) * 10 y-axis series of 300 doubles (randomly generated between 0 and 100) * Eclipse Helios * BIRT v2.6 * Windows XP SP3 * Intel Core2 Duo T9600 @2.8GHz, 1.59GHz * 3GB RAM Reproducible: Always Steps to Reproduce: 1. Unzip the code attached in Birt_Example_Perf.zip 2. Import it via the "Existing Projects in Workspace" wizard 3. Run src/org/eclipse/birt/chart/examples/api/viewer/SwtChartViewerSelector.java as a "Java Application" 4. See the "Painting the control took: %d ms" logging lines in the console. The results are different the first time (probably due to caching affects) when repainting the window (e.g. due to other windows being put in front and then removed), and when resizing the window. Note the repainting performance is really a bug in the test app since it should cache the chart bitmap and simply blit that to the screen rather than reconstructing it from scratch. However, the initial drawing and resizing performance issues are what really concern me.
Created attachment 175202 [details] Test code used to reproduce the bug
See also the following discussion on the BIRT forum that caused this bug to be raised: http://www.eclipse.org/forums/index.php?t=rview&goto=549024#msg_549024If
After investigation, rendering time is mainly spent on two fuctions: SwtRenderImpl.fillPolygon and drawline. For rendering one series, it will take 500ms while on swing device it's only 30-40ms. 1289903293203flushbbb 1289903293203bFillPolygon 1289903293375aFillPolygon 1289903293375beforeflushlines 1289903293375bDrawLine 1289903293375aDrawLine 1289903293375bDrawLine 1289903293390aDrawLine 1289903293390bDrawLine 1289903293390aDrawLine ........ 1289903293734bDrawLine 1289903293734aDrawLine 1289903293734bDrawLine 1289903293734aDrawLine 1289903293734beforeflushmarkers 1289903293734beforeflushlabels The series contains a lot of line so drawline will be invoked many times. Most of the invocations take no time but some of them will take about 15ms. I don't know what cause the difference.
Recent result shows that the random drawing is caused by gc. For some specific coordinate value, gc will spend more time to draw it. The following is a part of the test result(separated the calculation from gc's drawline code): 1291192686171-befdrawline 1291192686171-calculate 1291192686171-befgcsdrawline 1291192686171-aftgcsdrawline 434,377,436,80 1291192686171-aftdrawline 1291192686171-befdrawline 1291192686171-calculate 1291192686171-befgcsdrawline 1291192686187-aftgcsdrawline 436,80,438,395 1291192686187-aftdrawline So i don't find any improvement which can enhance the swt's drawing performance.
Since there are no obvious performance improvements to be made after investigation, we are canceling this as wont fix.
