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.
dev build 200301300100 Sun JDK 1.4.1 When I unmaximize editor windows and drag them very quickly left and right the drag motion is very choppy and CPU levels rise to 100%. My guess is that this is a JDK thing, but it is worth nothing that SwingSet2 that comes with the JDK, cpu usage is still high when dragging large MDI windows left/right very quickly but that is somewhat expected because the entire window is being redrawn. In the case of Netbeans, however, only the window outline is being drawn so I don't expect it to be choppy. Can you please point out the code being used by Netbeans so we may further debug the problem? Thank you, Gili
I guess there is a issue about this already. Normal Swing app JDesktopPane+JInternalFrames is fast comparing to our window. However there are used sublclasses InternalFrameType impl and DesktopPane (see in org.netbeans.core.windows.frames package), and I guess there could be some problem that handling some events could take too long. Worth to investigate.
I already investigated that. Unfortunately even if only outline is dragged whole MDI desktop is painted (I used OptimizeIt to see where the most time is spent.) If you close all other windows (Explorer, Output window) it is better. I do not know if it is possible to avoid painting of whole MDI desktop. See issue #30749.
I must add there is no special code performed in NB I am aware of when internal frame is dragged. Only paint() is called (often).
The solution (to me) is to make the desktop paintComponent() code smarter such that it does not bother trying to redraw components outside the repaint rectangle. I know Swing provides a mechanism whereby if you paint outside the limits it just ignores the operation but you should not bother calling expensive paints in the first place.
Problem is probably following, there are called repaint(), instead of repaint(<some reasonable cplipping region>). The repaint() then request to paint everything. Marek are those calls performed from NB? If yes, they should be adjusted just to the needed clipping region. I think that's the problem, I had a similar one when making the split painting in PerimeterPane.
I do not know. In OptimizeIt I see only painting itself called from RepaintManager which is asynchronous but I do not know who is responsible for paint/repaint requests.
The performance of the drag operations in MDI mode could be SIGNIFICANTLY enhanced by changing the default dragmode from JDesktopPane.OUTLINE_DRAG_MODE to JDesktopPane.LIVE_DRAG_MODE. Right now in Netbeans in MDI mode, the default dragmode for a JDesktopPane is JDesktopPane.OUTLINE_DRAG_MODE, which means that only the outline of an internal frame being dragged is moved. This takes a lot of processor time and explains why the CPU usage goes up when internal frames are being dragged. A better solution would be to change the dragmode to JDesktopPane.LIVE_DRAG_MODE, which newer Java JDK version support. When internal frames are dragged in this mode, it is mostly a fast hardware blit operation and much faster than moving of only the outline of the internal frame, because the latter is a pure software solution. I reported this enhancement request independently in Issue #33074. The fix should be very easy: Just the default dragmode in the Netbeans IDE (for the MDI mode) would have to be set to JDesktopPane.LIVE_DRAG_MODE instead of JDesktopPane.OUTLINE_DRAG_MODE. This can be done via a single call of the method JDesktopPane.setDragMode(int dragmode). See Java API docs for class javax.swing.JDesktopPane
I find it kinda funny that live dragging is faster than outline dragging. Anyway.. aside from fixing this specific bug, please consider revisiting the implementation of repaint() and making sure it doesn't redraw the entire JDesktop on a repaint request with clip bounds.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
issue doesn't apply to new window system - verified