Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 33023 - PropertyPanel too slow when used as CellRenderer
PropertyPanel too slow when used as CellRenderer
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Explorer
3.x
PC All
: P3 (vote)
: 3.x
Assigned To: _ tboudreau
issues@platform
: PERFORMANCE
Depends on: 31896
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-17 16:09 UTC by David Simonek
Modified: 2008-12-22 18:49 UTC (History)
0 users

See Also:
Issue Type: DEFECT
:


Attachments
output from optimization tool showing time distribution of repaints of TreeTableView (84.78 KB, text/html)
2003-04-17 16:11 UTC, David Simonek
Details
Patch to Node for soft cacheing property editor (1.48 KB, patch)
2003-04-17 23:00 UTC, _ tboudreau
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Simonek 2003-04-17 16:09:18 UTC
PropertyPanel is used as cell renderer in
TreeTableView. Common good technique of
implementing getComponent() of renderer is to
return still the same component, with different
model (data).
Unfortunately, PropertyPanel.setModel is too slow
for this purpose. The result is that we have to
create and cache hundreds of various
PropertyPanels, which eats memory (and is
complicated and not blazingly fast either).

Attached is output from optimization tool, when
TreeTableView was modified to call
PropertyPanel.setModel from getComponent.
Comment 1 David Simonek 2003-04-17 16:11:15 UTC
Created attachment 10003 [details]
output from optimization tool showing time distribution of repaints of TreeTableView
Comment 2 _ tboudreau 2003-04-17 22:58:13 UTC
Adding to PropertyPanel rewrite umbrella (propertypanel should
reuse rendering infrastructure from new property sheet).  It
will happen after property sheet is finished.

PropertyPanel is currently way too heavy to use as a cell
renderer (blame it on SheetButton).

You might be able to get some better performance if you
can cache and reuse some of your PropertyPanels - I don't
know what your code did - if it created new instances per

Also, it looks like one performance hit is getPropertyEditor().  I'll
attach a patch I would like to
incorporate into Node (it was committed once and removed,
but Jesse now approves it), to do soft cacheing of property
editors.  Maybe it will help a little for now.
Comment 3 _ tboudreau 2003-04-17 23:00:17 UTC
Created attachment 10008 [details]
Patch to Node for soft cacheing property editor
Comment 4 _ tboudreau 2003-10-07 19:18:31 UTC
FYI, this should be fixed soon - I've got a rewrite of PropertyPanel 
which should be considerably faster, using the property sheet's 
rendering/editing infrastructure.

The amount of work going on in TTV is indeed terrifying (since I have
a bunch of logging code embedded in PropertyPanel right now, I get
to see just how much).

I hope to be able to expose publicly a method like
renderProperty (Graphics g, Property p, Rectangle r) 
or
JComponent getPropertyRenderer(Property p)
which will render the property correctly and very, very quickly
Comment 5 _ tboudreau 2003-10-22 23:13:26 UTC
I just tried optimizing TTV to reuse a single property panel for 
painting, using the property panel from the proppanel_rewrite2 
branch.  I made sure the new property panel was pretty heavily
optimized for this use case.

WOW.  The options dialog seems to come up in about 1/4 the time
as before, and navigating between panes in the Import Management
Tool is almost instantaneous.

I had no idea PropertyPanel was so much of TTV's problem.
Comment 6 _ tboudreau 2003-12-09 09:36:55 UTC
Property panel rewrite branch merged.
Comment 7 Marian Mirilovic 2005-07-13 13:25:27 UTC
closed


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