This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 92947 - Performance of large processes slows down because of dashed lines
Summary: Performance of large processes slows down because of dashed lines
Status: VERIFIED FIXED
Alias: None
Product: soa
Classification: Unclassified
Component: BPEL (show other bugs)
Version: 6.x
Hardware: All All
: P2 blocker (vote)
Assignee: Alexander Permyakov
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2007-01-22 12:11 UTC by Michael Frisino
Modified: 2008-04-11 13:11 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Demo project, 7-times large then TRS. (318.97 KB, application/octet-stream)
2007-07-18 16:41 UTC, Alexey Anjeleevich
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Frisino 2007-01-22 12:11:36 UTC
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
dashed lines).

Alternatives are:
- 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.
Comment 1 Alexei Mokeev 2007-02-09 13:11:43 UTC
Added EP551_WAIVER_REQUEST keyword per request from
Sergey Lunegov:
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.

Thanks,
Sergey
Comment 2 Sergey Lunegov 2007-03-02 08:51:32 UTC
Probably also waive it. Since don't have input from HIE
Comment 3 Alexei Mokeev 2007-03-05 17:24:52 UTC
Removed Beta EP551_WAIVER_APPROVED keyword - we are going forward to FCS.
Comment 4 dpavlica 2007-06-07 09:02:09 UTC
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.
Comment 5 Sergey Lunegov 2007-06-07 09:35:32 UTC
Hi Dusan,
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.
Comment 6 _ rkubacki 2007-07-18 10:10:36 UTC
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?

Comment 7 Alexey Anjeleevich 2007-07-18 16:40:25 UTC
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
structure.

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. 















Comment 8 Alexey Anjeleevich 2007-07-18 16:41:47 UTC
Created attachment 45332 [details]
Demo project, 7-times large then TRS.
Comment 9 _ rkubacki 2007-07-24 10:10:10 UTC
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
rendered? 
Comment 10 Jiri Prox 2007-09-17 20:23:11 UTC
Obsolete milestone, please reevaluate
Comment 11 Sergey Lunegov 2008-01-18 10:13:07 UTC
Need reeavaluate again
Comment 12 Alexander Kouznetsov 2008-02-12 15:58:58 UTC
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.
Comment 13 Alexey Anjeleevich 2008-02-15 13:31:17 UTC
Alex, please replace dashed lines with solid.

Use colors
1) new Color(0xEEEEEE) for dashed bordres
2) new Color(0x5668CA) for message connections
Comment 14 Alexander Permyakov 2008-02-20 14:26:24 UTC
fixed 
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
Comment 15 Andrei Chistiakov 2008-04-11 13:11:53 UTC
Verified with NetBeans IDE 6.1 RC1 (Build 200804100130).