Community
Participate
Working Groups
I've previously opened Bug 273313 because of a behavior difference between carbon and cocoa for methods Control#getBackgroundColor() and Control#getForegroundColor(). The bug was fixed in a way which is OK for most usages but I still have performance worries with my use case. In the Nebula Gallery widget, I need to paint items with foreground / background colors specified in items. Since the layout is grid based and because of the typical usage of the widget, there are easily 100-500 items visible at the same time. On painting, I need to check foreground and background color of every item. On previous version of the widget I had overridden the get/set Background/Foreground Color as simple getter/setters so I got the same color object for all items. Example : 200 items w/ Blue BG and null (default) FG 200 items w/ red BG and null (default) FG 100 items w/ white BG and null (default) FG -> 3 Color objects in memory on painting, 0 Color objects created in one paint Now I had in bug 218104 a request to support Color inheritance from parent control by removing my overriding methods. This sounds a very good request. But with current Control methods, I get a new object returned on every call. Example : 200 items w/ Blue BG and default FG 200 items w/ red BG and default FG 100 items w/ white BG and default FG -> 1000 Color objects in memory on painting, 1000 Color objects created in one paint. (Since color are now inherited from parent, I don't even get null values so it's really 1000 new objects in any case) Now play with real time resizing (this requires a full paint): 25 frames per second : -> 1000 * 25 = 25000 new objects per second. Sure, I also create other objects in my drawing code, but removing these new Color objects seems a rather good performance enhancement that may also benefit other SWT applications. An other idea would be to add some protected methods which could return the current color object without creating a new one in order to be used by a subclass.
Sorry guys, just after posting I realized that I made a mismatch between Control and Item. This whole explanation is not valid, the performance impact of the Control behavior is probably very small (25 Colors per second only). Just forget this bug.
... After digging a little more, this bug and explanation are valid after all : Item#getBackground() / getForeground() is implemented this way : return background != null ? background : parent.getBackground (); in Table, Tree and now in Gallery. So we can have the performance issue when no color is set for items : parent.getBackground() /foreground is used at every call thus creating new objects every time.
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.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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. -- The automated Eclipse Genie.
