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.
Summary: | Tooltips in Outlinewview causing GUI to freeze randomly in Windows | ||
---|---|---|---|
Product: | platform | Reporter: | nicklas.lof |
Component: | Outline&TreeTable | Assignee: | Martin Entlicher <mentlicher> |
Status: | REOPENED --- | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: |
Profiler snapshot
new profiler snapshot memory snapshot |
Description
nicklas.lof
2011-01-13 14:35:43 UTC
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... |