Bugzilla – Full Text Bug Listing
| Summary: | CCombo creates too many shells | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Kevin Barnes <cocoakevin> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | NEW --- | QA Contact: | |||||
| Severity: | enhancement | ||||||
| Priority: | P3 | CC: | eclipse.felipe, elias, skovatch | ||||
| Version: | 3.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Kevin Barnes
Created attachment 148799 [details]
CCombo share shells
This patch creates one Shell for all CCombos in a Shell to reuse.
Sad to see this lingering for almost a year. Now the patch is stale. Would be great to see this in 3.7. Kevin, why wasn't your patch ever released ? Elias, is this behaviour causing problems for you ? Felipe, Seemed risky and I wasn't sure that it solved any problem. Creating a new window was/is expensive, but the memory is reclaimed when the window is destroyed. Other performance improvements were found and no one argued that this one was needed. From inspecting the code I see that each CCombo creates a non-visible Shell for the popup immediately (in the constructor). This seems a waste, since out of many CCombos, only a few will ever be dropped down (i.e. need the Shell). Those Shells are not reclaimed until the CCombo is disposed or reparented. I think it would be best for me to create a demo app with a couple hundred CCombos and see what difference it makes with a profiler. (if it's bad, I'm willing to contribute a patch since we use CCombo a lot) Do you think it's a good next step? I won't comment on what the next step should be since I'm no longer involved in SWT, but if I were still involved, I would be more interested in improving Combo to meet the needs of CCombo users (because CCombo sucks on mac). Thanks Kevin, I agree with you. If the patch is not fixing anything then it should not go in. I'm closing this as wont fix. Elias, If you find the time, try to benchmark a your app with and without the patch. I believe you won't see any difference. Creating a demo app with thousands of ccombo is probably not worth (too artificial). Kevin, why CCombo sucks on Cocoa ? Where are the real problems ? (In reply to comment #7) > Kevin, why CCombo sucks on Cocoa ? Where are the real problems ? I can answer that. The overall problem is that a CCombo looks nothing like the native Combo, so it's more obvious that it's a Java-based control. Compare CCombo from the CustomControlExample vs. Combo in ControlExample. -- CCombo is smaller than Combo -- CCombo's drop down arrow doesn't have blue background. -- CCombo has no focus ring around the control when focused -- CCombo popup window doesn't have a shadow -- CCombo's popup window becomes active/focused, so the menu bar of the parent window clears -- clicking outside of a CCombo doesn't hide the drop down menu. -- no visible difference in a READ_ONLY vs. editable CCombo. It looks like the text should be edible but clicking on it doesn't do anything. The text shouldn't be selectable, nor should it have a selection. Maybe we should start a new bug. I see that CCombo isn't designed to look or behave like the native Combo box, but as written it seems to be a replacement for the Win32 Combo. 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. |