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.
Original status: 1-Dispatched; Suggested Status: NEW These items should be added to the Keywords: PERFORMANCE Original submitter: petersl Description: Coke milestone build tpr2 on MacOS ppc & intel platforms. Before the diagram window scroll bars show up, all actions are responded within reasonable time. Once scroll bars show up, any action takes 3 to 5 seconds to respond, eg, create a new element, click on an element to select, move an element to a different location, popup the context menu for an element, click on the scroll bar or scroll bar arrow to scroll, etc. While the performance issue is there, doing a relayout with any layout style will re-gain the normal action response time. Sometimes scroll bars exist as a result of a relayout, the performance issue still does not exist. However, manaully moving elements out of the visual drawing area to enable the scroll bars will result in the performance issue consistently. See attached thread dumps when the performance issue exists for different actions. The first set of dumps starting with "thread-dump-" were taken on MacOS/intel platform with the -J-Dapple.awt.graphics.UseQuartz=false flag for different action. The 2nd set of dumps starting with "creation-" were taken during element creation when the performance issue first started. 2 dumps were taken with the flag and 2 were taken without the flag. Evaluation: Here are the testing result for different OS and JDK combinations: - OSX 10.4.5 and JDK 1.5.0_06, the performance problem does NOT exist - OSX 10.4.5 and JDK 1.5.0_05, the performance problem STILL exists SEE Attachments in BT issue.
To clarify the testing results in the Evaluation section, note that "-J-Dapple.awt.graphics.UseQuartz=false" flag is used in the testing for invoking IDE in these configurations. - OSX 10.4.5 and JDK 1.5.0_06, the performance problem does NOT exist - OSX 10.4.5 and JDK 1.5.0_05, the performance problem STILL exists
Created attachment 34624 [details] creation-thread-dump
Created attachment 34625 [details] creation-thread-dump2
Created attachment 34626 [details] creation-thread-dump-noflag
Created attachment 34627 [details] creation-thread-dump-noflag2
Created attachment 34628 [details] creation-thread-dump-noflag2
Created attachment 34629 [details] thread-dump-layout
Created attachment 34630 [details] thread-dump-move-class
Created attachment 34631 [details] thread-dump-popup-menu-on-class
Created attachment 34632 [details] thread-dump-popup-menu-on-class
Created attachment 34633 [details] thread-dump-scroll
Created attachment 34634 [details] thread-dump-scroll2
workaround: add flag "-J-Dapple.awt.graphics.UseQuartz=false" flag to netbeans_default_options will solve the problem in jdk 1.5.0_06. This bug has already been fixed in jdk 1.6.0 so the flag is not needed if using jdk 1.6.0.
Zooming and Scrolling result in an unusable UML-Tool, even on a 2.5GHz Dual G5 PowerMac with 2GB RAM a Diagramm with 8 Classes or mor could not be handled in acceptable speed! Highly need for Performance Issues to be done!!!
works on 1.5 with flag from Issue 78346 (initially suggested as flag for performance improvement)
please ignore last comment
Add a reference to the Apple bug filed. The Apple's bug# is 4453351. Apple already closed this bug since the problem is no longer reproducible with the latest build of Java SE 6.0 Release 1 DP6 as indicated in bug 4453351.
Waiver candidates from 7/12/2007 bug scrub.
Assuming you're using JScrollPane, there are several repaint strategies available for JScrollPane. Possibly simply using a different scroll mode for the viewport could offer a workaround. Was this tried? http://java.sun.com/j2se/1.4.2/docs/api/javax/swing/JViewport.html#setScrollMode(int)
Depends on the port to the netbeans graph library, currently scheduled for after 6.1.
Problem is no longer present with latest Mac JDK and port to NB visual library.
verified in build 20080807. Problem no longer exists in NB 6.5.