There is problem with performance of rendering dashed lines in Java 2D. Compared
to solid lines, the dashed line rendering is extremely slow.
The BPEL process currently uses dashed lines for message flow, connection lines,
and for container borders.
The performance is acceptable for relatively small to medium processes. It is
not a problem for TRS sample for instance. But for larger projects (perhaps 5x
size of TRS) the performance of diagram rendering (particularly scroll and
redraw) is absolutely unnaceptable.
Recommendations are to change the lines to solid instead of dashed.
But issue is diagram readability and compliance with BPMN notation (which uses
- Alternative 1) Commit to solid lines and make this change in diagram.
- Alternative 2) Allow user to choose "line style" (dashed or solid).
Another optimizaton opportunity is to not draw the message flow lines that are
completely vertical through the view port. Since these flow lines have no
visible connection in the view port they do not provide any useful information
and just compete for space with other more significant lines.
Added EP551_WAIVER_REQUEST keyword per request from
92947: Performance of large processes slows down because of dashed lines
The reason to waive is that to replace dash lines in BPEL diagram we need
input from HIE. And this input can't obtained in Beta timeframes.
This issue was raised by development team so most probably no impact on customers.
On existing samples performance is quite good.
In case of user complains we can implement simple workaround and deliver in some
of milestone builds via netbeans.org.
It will be fixed by FCS after HIE input will be obtained.
Probably also waive it. Since don't have input from HIE
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Could you send me the link to that BPMN notation please?
Then I would like to ask...Do you plan to switch to Graph library which is used
in Mobility and Visual Web pack sometimes in the future? Could that library
solve the performance problem then?
Or what about to draw pictures instead of lines? Would that help?
How drawing of pictures is related to the overall performance?
According to your two alternatives. I would prefer the 1) then 2) because of bad
discoverability of such kind of "switcher". But I am not familiar with the BPMN
notation, so i don't know how strictly it should be done with respect to that.
you can find BPMN spec at http://www.bpmn.org/.
We will not switch to Graph library. And in any case Graph library can't help
us: this performance problem is caused by java2D issues.
This is very vague report. For me the description and evaluation does not justify the waiver. Can we add test case +
exact description of slow operation + measurements (times and environment description)?
If we blame Java2D to be the slow is there bug filed against JDK?
Java2D uses third party native library for graphics rendering when
antialiasing(AA) is turned on or scale factor is another then 1.0.
We use both: AA and scale. Diagram without AA looks like from XX century,
and this is unacceptable, scale is used for zoom.
Java2D group know about problem of slow rendering of dashed lines, but "Will they fix it?"
and "Is it possible to fix this?" are antother questions.
Also as I know they work on migration to another native graphics library. But will this help?
One more question: "If it is possible to fix, can we wait for that moment? NB should work good on JVM from version 1.5,
which will not contain fix".
Rendering of dashed path is very expensive operation even if it is implemented in assembler,
and highly optimized. How works algorithm of dashed path rendering? All shapes and pathes
in 2D graphics are described by list of line segments and Bezie curves of second and third order.
(e.g rounded rect consists from 4 line segments and 4 curves of third order). To render dashed path:
1) At first path should be spliteted in list of small segments, this list can be very large, for splitting
length of every path segment and total length of path are calculated (for curves length calculated
aproximatly by iterative methods).
2) Around every segment small shape is constracted (if small segment is line then shape
is rectangle or rounded rectangele, if small segment is curve or it is contains point of
connection of two sequential path segments then small shape can be very complex)
3) And then this giant list of small shapes (which are going along path) should be filled
Of course this steps can be optimized, but anyway every of this steps is very expensive.
Rendering of big number of dashed pathes decreases performance dramaticaly through objective reasons
(algorithm complexity), that's why I am don't beleave that Java2D group can help.
Design of application which takes into account this problem (which in fact just a feature) is best choice.
In other words: solid lines shoud be used everywhere it is possible. Dash property can be replaces by
color and decorations.
But BPMN specifies view of elements and if we stop to use dashed lines, then we stop to be BPMN-compatible.
Here "political" decision is needed.
In attachment you will find demo project which seven times larger then TRS, it is created by copying of sequence "Main"
six times. Scrolling is unaccaptably slow independently what JVM (1.5 or JVM 1.6) is used. It is faster on JVM 1.6, but
it is not enough faster. Please note that dashed pathes length depends on activities count as well as on on diagram
What we did?
1) Experiment with cahnging all dashed lines to solid - this is solves problem
2) Made expreiment with turning AA off, and tried to optimaze pathes rendering on our side. This helped gently.
3) Simple test case, which renders a lot of big dashed rounded rectangles on canvas, this test case also confirmed
that solid pathes are rendered much faster then dashed.
4) Сonsulted with Java2D group.
Created attachment 45332 [details]
Demo project, 7-times large then TRS.
I tried this on my laptop (SonyVaio 2x2GHz/2GB/running Ubuntu Linux 7.04, JDK6.0u1)
It takes 65 secs to scroll down with solid lines but 190 with dashed ones.
I am not convinced yet that we cannot improve this. Waiver for 6.0 can be OK. Did we tried to clip the path before it is
Obsolete milestone, please reevaluate
Need reeavaluate again
According to bug priority guidelines P1 is more suitable for this issue:
- scalability problem of a feature making the feature unusable in a usual scenario
If the size of BPEL diagram is big enough (like in the attached sample) most actions start to take tens of seconds. This
makes the feature almost unusable.
Alex, please replace dashed lines with solid.
1) new Color(0xEEEEEE) for dashed bordres
2) new Color(0x5668CA) for message connections
HG: changed bpel.editors/src/org/netbeans/modules/bpel/design/geometry/FPoint.java
HG: changed bpel.editors/src/org/netbeans/modules/bpel/design/geometry/FStroke.java
Verified with NetBeans IDE 6.1 RC1 (Build 200804100130).