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.
In Windows the tooltips in the Outlineview seems to cause the GUI to freeze if the application is maximized and the tooltip is drawn on the right hand side of the screen. Usually when the tooltip is so big that it will be drawn "outside" the screen but can't say for sure thats the case all the time. During the freeze the application doesnt respond at all and it can be frozen for anything like 10 seconds to minutes using full CPU on one core. No exceptions are thrown but slowness are detected and the usual Too much time in AWT-thread error. I have seen the GUI to freeze in the same way even when the tooltip was drawn in the middle of the screen but haven't been able to reproduce it myself. It only seems to happen on Windows (both XP and Win7 with latest java installed jre6_u23) I haven't been able to reproduce it on Mac. It also seems to be happen when the application is in a normal sized window that is bordering the right hand side of the screen. I'm attaching a profiler snapshot from one of the sessions when the GUI did freeze. I can't say for 100% that it's not something in my underlying BeanNodes and datamodel causing this but since it's only happening on Windows I find it hard to believe. Also the property of the Nodes is static and not computed for each get.
Created attachment 104957 [details] Profiler snapshot
It seems to happen less often on faster computers. I had some problem reproducing it myself when running the application standalone but while running it using the profiler it became slow enough to start trigger quite fast.
Nicklas, it's a pity that you've excluded Java core classes during profiling. org.netbeans.swing.tabcontrol.TabbedContainer.paint(java.awt.Graphics) spends a lot of time in org.openide.explorer.propertysheet.PropertyPanel.removeNotify(), but it's not visible what it does. But the problem does not seem to be in tooltips. Can you please profile the TabbedContainer.paint() as a root method with profiling of all classes?
Created attachment 105100 [details] new profiler snapshot Here is a new profile snapshot with not classes filtered and with TabbedContainer.paint() as a root method. I had problems running profiling with all classes. So I had to launch the appliaction standalone outside netbeans, trigger the freeze and then attach the profiler to even have a chance to trigger the freeze. Doing profiling without this cause the netbeans plattform application take full CPU all the time making it completly impossible to trigger the freeze.
Thanks for the full profiling. There is some component with 266 thousands children! javax.swing.JComponent.paintChildren(java.awt.Graphics) iterates 266 thousand times through it's subcomponents and calls getComponent(), isLightweightComponent() and isVisible() on them. But it does not call paint() and other associated methods, therefore isVisible() must have been false. Please check components that you add into your property displayer. Some (or all of them) have more than 266 thousand invisible children. And this makes the painting slow.
(In reply to comment #5) would a memory snapshot help here? I can't see where these 266000 children would come from (and only when window is fullscreen and in Windows only) . It's a normal outlineview with about 50 BeanNodes without children displayed. I have done a memory profiling and the only unusual number of objects I can see i sun.java2d.pipe.Region and java.awt.Point that shoots away like crazy when the freeze happens with 150.000-200.000 Live objects slowly counting. When the freeze is over it drops down to about 7000. I will attach it.
Created attachment 105114 [details] memory snapshot
I tried to reproduce this for Geertjan.W yesterday but I couldn't. The only thing we have done in the application is that the outlineview is now readonly. So I did enable read/write for the properties again and the freeze doesn't happen. Then I did set suppressCustomEditor to false (so it's showing the [...]-button) and boom the application did freeze within a few seconds (when running in memory profiling the bug is very easy and fast to trigger) and the customeditors supressed is the builtin standard String editor. By looking at the code for ButtonPanel paint() method I found some comments about "endless looping on windows" which kind of describe excactly what I am experince here.
I can not reproduce the freeze in current 7.1 dev builds on Windows. Maybe it was already fixed by some other changes? If not, we'll look at it into NB 7.2...