Bug 220546 [Decorators] performance problem with resource manager in decoaration context
20080217 I'm afraid the solution to use the IDecorationContext to provide a resource manager introduces a performance degregation. The DecoratorManager, who manages the light weight label decorations, stores decorations by context DecorationScheduler.resultCache<IDecorationContext, Map<DecorationResult>> Most label providers used the default context (DecorationContext.DEFAULT_CONTEXT). If there were several requests for the same image, all the requests were bundled and the result was only computed once before the result was broadcasted to all viewer. Now, with the new code, each label provider has its own instance of a decoration context. There will be separate computations per context. Even if two viewers want to decorate the same image, each of them will have to compute a DecorationResult The broadcast, however, still goes to all viewers.
bundles/org.eclipse.jface/src/org/eclipse/jface/viewers/DecoratingLabelProvider.java
return null;
	}
	/*
	 * (non-Javadoc)
	 * 
	 * @see org.eclipse.jface.viewers.IColorProvider#getForeground(java.lang.Object)
	 */
	public Color getForeground(Object element) {
		if (provider instanceof IColorProvider) {
			return ((IColorProvider) provider).getForeground(element);
		}
		return null;
	}
	/**
	 * Return the decoration context associated with this label provider. It
	 * will be passed to the decorator if the decorator is an instance of
	 * {@link LabelDecorator}.
	 * 
	 * @return the decoration context associated with this label provider
	 * 
	 * @since 3.2
	 */
	public IDecorationContext getDecorationContext() {
		if (decorationContext == null) {
			decorationContext = new WrappedDecorationContext(
					DecorationContext.DEFAULT_CONTEXT);
		}
		return decorationContext;
	}
	/**