Community
Participate
Working Groups
And many other SWT objects like colours in ColorConstants and images in FlyoutPaletteComposite for example. There is a nice Sleak tool available from SWT team that may be in help to track them down.
They are not meant to be disposed. They are static variables and need to be available for as long as the workbench is open.
I see; but there still may be problems with motif though I'm not sure. SnapFeedbackPolicy on line 72 also makes burst colours allocation without dispose ((( About GC - it's a very limited resource in many systems; it's not good to keep it for a long time slice since other applications may starve. Look at SWT impl code - it is deallocated as soon as possible!
Colors are not resources. You can construct as many as you want and not crash the OS. I don't know much about Motif. How big is a GC? How many can you have? And what do you suggest without sacrificing performance?
(In reply to comment #3) > Colors are not resources. You can construct as many as you want and not crash > the OS. Really? I've had the understanding that they are... sometimes. In the "Managing Operating System Resources" article in the section entitled "A note about Color" the author states... "Color is just like any other SWT resource-based object... If you are using a high-color (direct palette) display and you forget to follow the rules for disposing Color, you may notice that nothing bad happens. But if the rules for disposing Color are not followed on a low-color (indexed palette) display, real problems can occur." Is draw2d making the assumption that it will never run on a low-color display? I understand that the topic of the bug is about static instances but want to make sure that this isn't applied globally in draw2d and if it is I'm curious as to why. > > I don't know much about Motif. How big is a GC? How many can you have? And > what do you suggest without sacrificing performance? For GC I always thought there were very few available. According to the GC javadoc Win95 and 98 have some restrictions but I don't have the specifics on that. "Application code must explicitly invoke the GC.dispose() method to release the operating system resources managed by each instance when those instances are no longer required. This is particularly important on Windows95 and Windows98 where the operating system has a limited number of device contexts available."
AFAIK, even on low-color displays, the colors are still not resources. The problem encountered, then, is not getting exact (or even close) matches for the requested colors. Windows 95 and 98 are not supported anymore. I do think, however, that the case mentioned in comment 2 should be fixed. SnapFeedbackPolicy can dispose those colors after it's done using them. Even if they're not resources, a reference count is maintained for those colors; and it seems they are not garbage-collected until disposed. You can end up with thousands of Color objects very quickly when showing snap feedback.
> "Managing Operating System Resources" article in the section entitled "A note > about Color" the author states... > "Color is just like any other SWT resource-based object... That's just wrong. Try it out. Create a few million colors and see what happens. > high-color (direct palette) display and you forget to follow the rules for > disposing Color, you may notice that nothing bad happens. But if the rules for > disposing Color are not followed on a low-color (indexed palette) display, real > problems can occur." The problem is that the color you allocated is not freed up when you attempt to allocate another color. It's not that serious of a problem given that colors aren't guaranteed to be available anyway. > Is draw2d making the assumption that it will never run on a low-color display? No, but some SWT functions have issues in 8-bit mode. for example, painting an Image with alpha values results in a black rectangle. > For GC I always thought there were very few available. According to the GC > javadoc Win95 and 98 have some restrictions but I don't have the specifics on that. javadoc??
> > For GC I always thought there were very few available. According to the GC > > javadoc Win95 and 98 have some restrictions but I don't have the specifics on > that. > javadoc?? Oops, for some reason I thought you were talking about win32 API which of course doesn't have javadoc :-).
Correction to my comment #5: I did a little test and the Color objects are indeed getting garbage-collected even if they're not disposed. I thought that since Sleak was showing all the Colors, they probably weren't getting GCed; but now it seems Sleak is just showing the colors based on the reference count, and not actual Objects.
Okay, so the only remaining issue here is whether or not it's okay to have static GCs that are never disposed. GC's javadoc does mention that there's a limited number available on Win95 and 98, but those platforms are not supported. As for Linux, perhaps Billy can shed some light on it. I doubt that this would be a problem. Marking as WONTFIX, meanwhile.
GCs under X are a limited resource, but not that limited. Just don't keep a few thousand around for fun. If it's less than 100 then I wouldn't worry about it.
*** Bug 155785 has been marked as a duplicate of this bug. ***
