Community
Participate
Working Groups
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.
Investigate for M5.
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
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.
Reopening and assigning to NE as he is investigating the TreeViewer optimizations.
CVS decorator is now performant enough. Need to reconsider decorators post 2.0.
Reopen to investigate
Significant performance work was done in 3.0 and 3.1. You are now passed and IDecoration and can do everything with that.