Community
Participate
Working Groups
ILabelDecorator operates on a base image and produces another image. For each active decorator in use, the total number of OS images required grows in a combinatorial way. The result is that Eclipse-based applications that make moderate use of decorators have huge resource requirements. For example, if there were 4 base images, and 4 decorators with 4 decorations each, this should only require 20 images. Instead, it potentially produces over 1000 Images (4^5). Now that SWT supports owner draw, images should rarely be combined and cached. It's not possible to just draw the images on top of each other, instead of constructing and caching every combination.
SWT and JFace now support OwnerDraw and we should look into OwnerDraw support for decorators in 3.4 - however this does not solve any backwards compatibility issues. Randy I think your math is pessimistic - I would be interested to see if you had an example of this sort of image load especially as it is quite rare than anyone uses anything other than the bottom right quadrant as JDT takes the bottom left. Playing around a bit in the SDK I peaked at 116. I understand that this is hardly any sort of exhaustive test but it dows give you a ballpark.
I did a similar test case and also saw 100 images instantly added. I was using an eclipse-based IDE which has it's own SCM with decoration similar to CVS. All decorators off: 673 GDI Objects All decorators on: 775 GDI Objects I had 2 CU editors open, one perspective, and some views open which use decorators. Enabling decoration added 100 images instantly, and there were *many* combinations which were not present in my scenario. Also, there is some decorator usage which can't be disabled, and thus makes up part of that base number. JDT is always showing me warnings, errors, static, abstract, final, overrides, extends, package protected, protected, private, java project, and interface. Out of 765 total resource handles, I would guestimate that 50% of all resource handles used by Eclipse are images that result from decorator composition. That's a significant amount, and I don't think it would be a challenge to hit 1000 doing nothing more than plug-in development in a team environment. As products extend the IDE with new decorators, base images, and project types, it becomes a real scalability concern.
I'm not diasagreeing with you Randy but this is going to be a big undertaking when we do it as it will require API changes to decorators and a shift of existing viewers to owner draw based label providing. This is certainly on our 3.4 list - thanks for the analysis.
*** Bug 188333 has been marked as a duplicate of this bug. ***
I recently discovered a feature in SWT/win32. If you have owner draw on a Tree, and the treeitem is clipped due to the size of the tree, the rollover popup that displays the full text no longer appears. You'd be surprised how often that popup is useful. IMO, this bug is blocked by SWT addressing the popup limitation. I'm not sure if there is already a bug open in SWT land.
Oleg is now responsible for watching the [Decorators] category.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
