Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320873

Summary: Chart Building / Rendering Performance Issues
Product: z_Archived Reporter: Adrian Issott <adrian.issott>
Component: BIRTAssignee: Birt-Chart-inbox <Birt-Chart-inbox>
Status: RESOLVED WONTFIX QA Contact: Xiaoying Gu <bluesoldier>
Severity: major    
Priority: P3 CC: adrian.issott, bluesoldier
Version: unspecified   
Target Milestone: 3.7.0   
Hardware: PC   
OS: Windows XP   
Whiteboard: Obsolete
Attachments:
Description Flags
Test code used to reproduce the bug none

Description Adrian Issott CLA 2010-07-26 04:37:01 EDT 
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.
Comment 1 Adrian Issott CLA 2010-07-26 04:38:30 EDT 
Created attachment 175202 [details]
Test code used to reproduce the bug
Comment 2 Adrian Issott CLA 2010-07-26 04:40:39 EDT 
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
Comment 3 Xiaoying Gu CLA 2010-12-07 01:39:59 EST 
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.
Comment 4 Xiaoying Gu CLA 2010-12-07 01:40:16 EST 
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.
Comment 5 Xiaoying Gu CLA 2010-12-07 01:40:45 EST 
Since there are no obvious performance improvements to be made after investigation, we are canceling this as wont fix.