Bug 195672 - 27s in MainWindow.paint(): components in RendererPropertyDisplayer grow
27s in MainWindow.paint(): components in RendererPropertyDisplayer grow
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Explorer
6.x
All All
: P2 (vote)
: 7.0.1
Assigned To: Jaroslav Tulach
issues@platform
EXCEPTIONS_REPORT perf-profileme
: PERFORMANCE
Depends on:
Blocks: 197680
  Show dependency treegraph
 
Reported: 2011-02-18 18:51 UTC by tbrunhoff
Modified: 2011-07-06 00:00 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
nps snapshot (73.43 KB, application/nps)
2011-02-18 18:51 UTC, tbrunhoff
Details
snapshot of ide while debugging (288.48 KB, image/png)
2011-02-18 19:58 UTC, tbrunhoff
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tbrunhoff 2011-02-18 18:51:41 UTC
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
Comment 1 tbrunhoff 2011-02-18 18:51:59 UTC
Created attachment 106170 [details]
nps snapshot
Comment 2 Jaroslav Tulach 2011-02-18 19:38:16 UTC
The MainWindow.paint ends up on ~650 calls to getNormalShape. Can this be caused by a huge amount of components on the screen?
Comment 3 tbrunhoff 2011-02-18 19:58:47 UTC
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.
Comment 4 Stanislav Aubrecht 2011-02-21 11:43:08 UTC
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?
Comment 5 Stanislav Aubrecht 2011-02-22 16:14:29 UTC
please provide the required feedback and reopen, thanks
Comment 6 Vladimir Voskresensky 2011-06-21 19:18:52 UTC
(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)
Comment 7 Egor Ushakov 2011-06-22 16:00:52 UTC
cnd debugger views column editor issue
Comment 8 Egor Ushakov 2011-06-23 14:39:00 UTC
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())
Comment 9 Egor Ushakov 2011-06-23 14:45:31 UTC
maybe it is worth adding an assert comp.isLightweight() just before calling SwingUtilities.paintComponent in RendererPropertyDisplayer
Comment 10 Egor Ushakov 2011-06-23 14:49:43 UTC
correction: StringRenderer and ButtonPanel sometimes sre lightweight and sometimes not...
Comment 11 Egor Ushakov 2011-06-23 16:54:40 UTC
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).
Comment 12 Egor Ushakov 2011-06-23 17:24:30 UTC
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.
Comment 13 Egor Ushakov 2011-06-27 13:28:23 UTC
could it be fixed in 7.0.1? It looks like a showstopper
Comment 14 Alexander Pepin 2011-06-28 10:25:43 UTC
It's really worth fixing in 7.0.1.
Comment 15 Jaroslav Tulach 2011-06-30 09:33:15 UTC
(In reply to comment #12)
> I believe we can just do removeAll() right after a call to

Do you believe or do you know?
Comment 16 Egor Ushakov 2011-06-30 10:13:20 UTC
(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.
Comment 17 Jaroslav Tulach 2011-06-30 14:43:56 UTC
ergonomics#dcf1fe629885 parent is release701_base
Comment 18 Quality Engineering 2011-07-02 14:08:23 UTC
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
Comment 19 Jiri Rechtacek 2011-07-04 08:12:28 UTC
Egor, Alexander, please verify the fix in latest daily build. If verified, will be backport to 701. If not, will be waived. Thanks
Comment 20 Egor Ushakov 2011-07-04 08:26:46 UTC
I'm unable to reproduce the issue in trunk
Comment 21 Alexander Pepin 2011-07-04 09:24:13 UTC
Can not reproduce it in trunk either.
Comment 22 Jiri Rechtacek 2011-07-04 09:56:19 UTC
Thanks, mark it verified in that case.
Comment 23 Alexander Pepin 2011-07-04 13:30:06 UTC
verified in dev build please push the fix into 7.0.1 release branch.
Comment 24 Jiri Rechtacek 2011-07-04 14:15:40 UTC
backport in release701 - http://hg.netbeans.org/releases/rev/fe75a4ddb3c4
Comment 25 Quality Engineering 2011-07-06 00:00:57 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo