Community
Participate
Working Groups
3.1M6 While looking around with the SWT spy plugin, we noticed that there are many Composites created as parents for toolbars which seem to be there to optimize layout operations. SWT now supports cached layout: can these be removed? It seems that optimizations in this area should be done at the SWT level, as creating extra Composite widgets when they are not necessary is itself a likely performance issue. Examples: - Every toolbar in the coolbar seems to have a composite parent - There seems to be two extra cache composites surrounding the perspective switcher - The CBanner seems to have a parent which is there for caching purposes
stefan were you aware of the SWT caching support? I agree that we should remove our own caching if SWT does this well.
Yes. AFAIK, the new SWT caching support is actually based on the workbench caching algorithm (the workbench stuff was written first). I haven't benchmarked the SWT caching yet, but I suspect that the composites around the top-level coolbar and the perspective switcher could be removed if it works well (however, this is a nontrivial change and only accounts for a small number of composites). The purpose of the composites around most toolbars is to avoid flicker, not to optimize layout caching. We use composites with SWT.NO_BACKGROUND in order to avoid changing the relative coordinates of toolbars. If they end up inside a NO_BACKGROUND composite, then moving the composite copies all the pixels and causes the toolbar to move smoothly. If we move the toolbar directly, it first copies the background colour and then draws the toolbar... which creates a LOT of flicker. If SWT could reduce the flicker in ToolBar.setBounds(...), we could remove these composites. This would be an easy code change and would eliminate a lot of composites. I'm not sure which case the composites in the coolbar fall under.
I know Steve was looking at the toolbar flashing on Windows thing, they don't flash on Linux-GTK+, you can tell by resizing the hierarchy view when it has a toolbar in the middle: flashes on Windows but not on Linux...
Stefan, how about entering a bug report for the flashing toolbars?
Stefan, I realize the you have bigger fish to fry than this but I am trying to debug toolbar flashing that was introduced in SWT since 3.0. If your code is working around our bug, it makes it hard. Can you tell us how we can temporarily remove the composites?
I just removed the composites for view toolbars, and it seems that the flashing issue is fixed. Nicely done. This just leaves the layout caching issue. When I last looked into this, the slow layouts were ViewForm, CBanner, and GridLayout. GridLayout seems to be better now, but ViewForm and CBanner still need caching. I originally reported this (and attached a fix + test cases) in bug 68957.
Committed patch that removes the extra composites around view toolbars.
I will add caching to ViewForm and CBanner.
I've just removed the extra composites used for the view dropdown and the extra placeholder used in PresentablePartFolder. That's most of them... but I'm not really seeing any measurable performance improvements. We could still reduce one composite per view and editor if we were to create views and editors directly inside the PartPane's composite, rather than in a child widget. (Note: the composites wrapping the perspective switcher and coolbar aren't a big deal because there's only ever 1 of each).
>>but I'm not really seeing any measurable performance improvements. There might be some improvements on Linux. Billy to retest.
There are currently no plans to work on this although we would be happy to review any patches
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.
