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 194304 - Tooltips in Outlinewview causing GUI to freeze randomly in Windows
Summary: Tooltips in Outlinewview causing GUI to freeze randomly in Windows
Alias: None
Product: platform
Classification: Unclassified
Component: Outline&TreeTable (show other bugs)
Version: 6.x
Hardware: PC Windows 7
: P3 normal (vote)
Assignee: Martin Entlicher
Depends on:
Reported: 2011-01-13 14:35 UTC by nicklas.lof
Modified: 2011-11-16 14:46 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:

Profiler snapshot (346.59 KB, application/octet-stream)
2011-01-13 14:38 UTC, nicklas.lof
new profiler snapshot (330.56 KB, application/octet-stream)
2011-01-18 15:36 UTC, nicklas.lof
memory snapshot (237.00 KB, application/octet-stream)
2011-01-18 19:50 UTC, nicklas.lof

Note You need to log in before you can comment on or make changes to this bug.
Description nicklas.lof 2011-01-13 14:35:43 UTC
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.
Comment 1 nicklas.lof 2011-01-13 14:38:01 UTC
Created attachment 104957 [details]
Profiler snapshot
Comment 2 nicklas.lof 2011-01-18 08:37:47 UTC
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.
Comment 3 Martin Entlicher 2011-01-18 13:55:10 UTC
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?
Comment 4 nicklas.lof 2011-01-18 15:36:09 UTC
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.
Comment 5 Martin Entlicher 2011-01-18 16:14:01 UTC
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.
Comment 6 nicklas.lof 2011-01-18 19:49:17 UTC
(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.
Comment 7 nicklas.lof 2011-01-18 19:50:30 UTC
Created attachment 105114 [details]
memory snapshot
Comment 8 nicklas.lof 2011-02-17 10:02:59 UTC
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.
Comment 9 Martin Entlicher 2011-11-16 14:46:07 UTC
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...