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.
Build: NetBeans IDE Dev (Build 201102170501) VM: Java HotSpot(TM) Client VM, 19.0-b09, Java(TM) SE Runtime Environment, 1.6.0_23-b05 OS: Linux User Comments: tbrunhoff: While debugging I started to edit the code, and it went away for a long time. apepin: open basic_string.h (.tcc) while debugging Quote Maximum slowness yet reported was 27293 ms, average is 21687
Created attachment 106170 [details] nps snapshot
The MainWindow.paint ends up on ~650 calls to getNormalShape. Can this be caused by a huge amount of components on the screen?
Created attachment 106175 [details] snapshot of ide while debugging > Can this be caused by a huge amount of components on the screen? Not sure how to measure "huge". I can say that the attachment shows what is "normal" for me, and that I frequently do editing while the debugger is running without seeing any delay at all, let alone 27 seconds.
java.awt.Component.mixOnHiding seems to be the problem. it suggests that heavyweight and lightweight components are mixed in the IDE which causes performance problems. i didn't find any suspicious or third-party module in your message log though. maybe the CND pack creates some heavyweight components? is this reproducible with pure java distribution of netbeans?
please provide the required feedback and reopen, thanks
(In reply to comment #4) > java.awt.Component.mixOnHiding seems to be the problem. it suggests that > heavyweight and lightweight components are mixed in the IDE which causes > performance problems. > i didn't find any suspicious or third-party module in your message log though. > maybe the CND pack creates some heavyweight components? what kind of components should we look at? > is this reproducible with pure java distribution of netbeans? it was just recently reproducible again (with cnd version)
cnd debugger views column editor issue
I investigated the problem, here are the conclusions: - for some reason when we register custom PropertyEditor for table columns (even if they are completely empty) an instance of RendererPropertyDisplayer inside the table starts to grow its number of components endlessly. And they are never removed after that but all of them receives removeNotify at every SynthTableUI.paintCells->rendererPane.removeAll() (PropertyPanel receives removeNotify and forward it to the RendererPropertyDisplayer contained in it) - InplaceEditors used in the tables (like StringRenderer or ButtonPanel) are NOT lightweight and calling SwingUtilities.paintComponent for them is very dangerous (see RendererPropertyDisplayer.painComponent())
maybe it is worth adding an assert comp.isLightweight() just before calling SwingUtilities.paintComponent in RendererPropertyDisplayer
correction: StringRenderer and ButtonPanel sometimes sre lightweight and sometimes not...
yet another idea: we use single StringRenderer but once it is wrapped with ButtonPanel (in RendererFactory.getRenderer) it's parent changes to ButtonPanel and when we try to render it with SwingUtilities.paintComponent CellRendererPane is created for it and each time added to the container (RendererPropertyDisplayer in our case).
I believe we can just do removeAll() right after a call to SwingUtilities.paintComponent in RendererPropertyDisplayer, that should remove all components added by SwingUtilities.paintComponent.
could it be fixed in 7.0.1? It looks like a showstopper
It's really worth fixing in 7.0.1.
(In reply to comment #12) > I believe we can just do removeAll() right after a call to Do you believe or do you know?
(In reply to comment #15) > (In reply to comment #12) > > I believe we can just do removeAll() right after a call to > > Do you believe or do you know? I tried it and it works fine. I know that SwingUtilities.paintComponent keeps populating RendererPropertyDisplayer with new CellRendererPanes because of the issues with ButtonPanel wrapping described here. Removing all new components from RendererPropertyDisplayer after the paint will definitely solve the issue, I'm just not sure that this is the best solution.
ergonomics#dcf1fe629885 parent is release701_base
Integrated into 'main-golden' Changeset: http://hg.netbeans.org/main-golden/rev/dcf1fe629885 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #195672: gorrus@netbeans.org suggested to call removeAll() right after SwingUtilities.paintComponent
Egor, Alexander, please verify the fix in latest daily build. If verified, will be backport to 701. If not, will be waived. Thanks
I'm unable to reproduce the issue in trunk
Can not reproduce it in trunk either.
Thanks, mark it verified in that case.
verified in dev build please push the fix into 7.0.1 release branch.
backport in release701 - http://hg.netbeans.org/releases/rev/fe75a4ddb3c4
Integrated into 'releases' Changeset: http://hg.netbeans.org/releases/rev/dcf1fe629885 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #195672: gorrus@netbeans.org suggested to call removeAll() right after SwingUtilities.paintComponent