Bug 10526 - [Decorators] Decorator mechanism does not allow for optimizations
Summary: [Decorators] Decorator mechanism does not allow for optimizations
Status: RESOLVED WORKSFORME
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P4 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Tod Creasey CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
Depends on:
Blocks: 10516
  Show dependency tree
 
Reported: 2002-02-28 16:37 EST by Kevin McGuire CLA
Modified: 2005-05-18 16:33 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin McGuire CLA 2002-02-28 16:37:30 EST
At present our decorators show up piecemeal because we do them in a background 
thread and thus the order they appear is 'random'.

The way we decorator mechanism works does not allow us to optimize in some 
areas.  Specificly:

1. The icon and text are asked for separately. This requires us to go to our 
sync info twice, which is on disk and expensive to get.

2. The decorators are asked individually.  In the case of CVS, all the sync 
info for sibling resources is in the same file, so its faster for us to 
determine all their decorators at once.

3. In order to avoid doing work in the UI thread, we create a background thread 
to generate the decorators.  When then need to tell the UI via an event that we 
now have decorators, and then they ask us for them.  It would be better if we 
could just give the UI the decorators we know about all at once.

Note: to be a good citizen we should be computing the decorators in a thread 
different than the UI context.

The combination of #2 and #3 could result in the decorators appearing in parent 
child ordering, with all siblings appearing at once.
Comment 1 Nick Edgar CLA 2002-03-11 15:41:49 EST
Investigate for M5.
Comment 2 Nick Edgar CLA 2002-03-28 13:21:59 EST
We are investigating a solution for 1.
For 2, we discussed this yesterday and it seems like this is no longer 
problematic for VCM.
For 3, as mentioned yesterday, we need to come back and ask for the decoration 
again in order to apply decorations in the correct order.

As for the order of appearance, I will be looking a TreeViewer update and may 
change it to process items in pre-order rather than top-down
Comment 3 Tod Creasey CLA 2002-04-01 09:42:08 EST
There is a solution for 1 in build 20020402. We now also allow for a 
LabelProviderChangedEvent to take multiple items so the number of requests for 
decoration will now be reduced dramtically.
Comment 4 Tod Creasey CLA 2002-04-01 09:43:18 EST
Reopening and assigning to NE as he is investigating the TreeViewer 
optimizations.
Comment 5 Nick Edgar CLA 2002-05-14 14:45:28 EDT
CVS decorator is now performant enough.
Need to reconsider decorators post 2.0.
Comment 6 Randy Giffen CLA 2002-08-09 13:02:49 EDT
Reopen to investigate
Comment 7 Tod Creasey CLA 2005-05-18 16:33:17 EDT
Significant performance work was done in 3.0 and 3.1. You are now passed and
IDecoration and can do everything with that.