Community
Participate
Working Groups
StackLayout becomes very slow when using it with a lot of controls. This is because it does not only layout the currently visible controls, but also the invisble onces. To change this only one line of code needs to be changed: protected void layout(Composite composite, boolean flushCache) { Control children[] = composite.getChildren(); Rectangle rect = composite.getClientArea(); rect.x += marginWidth; rect.y += marginHeight; rect.width -= 2 * marginWidth; rect.height -= 2 * marginHeight; // Do not update bounds // when the component will not be visible. // In the update bounds all descendents will // start layouting as well and we do not want this! for (int i = 0; i < children.length; i++) { // Current code: children[i].setBounds(rect); // Should be: // if (children[i] == topControl) children[i].setBounds(rect); children[i].setVisible(children[i] == topControl); } } This worked on my pc. Im am new to SWT so maybe I am wrong, if there is a better way please let me know.. Kind Regards, Nick
There is a suggested fix for this. Could someone take a look at it? :)
theoretically this change can break clients, in practice I find it unlikely.
(In reply to comment #1) > There is a suggested fix for this. Could someone take a look at it? :) Remy, is this problem affecting you ?
(In reply to comment #3) > (In reply to comment #1) > > There is a suggested fix for this. Could someone take a look at it? :) > > Remy, is this problem affecting you ? No, not me at the moment. I was actually looking for some other bug that I was CC'd on and found this on my query and noticed that it was assigned to Veronika so I thought I'd punt it back to inbox.
We should make this change.
Fixed > 20100114. I tested with topControl set to null, and with varying sizes of stack pages, and with Eclipse. I don't see how this could break existing apps. It is safe and simple and it would definitely make StackLayout lay out faster if there are lots of controls not showing. Thanks, Nick!
This fix will be in 3.6 M5.
(In reply to comment #7) > This fix will be in 3.6 M5. I'd have moved the call to setBounds() outside the for(...)
Good point. Done. The layout code now reads: ... for (int i = 0; i < children.length; i++) { children[i].setVisible(children[i] == topControl); } if (topControl != null) topControl.setBounds(rect); }
I have reverted StackLayout back to the original, before the patch, and I am reopening this bug. For some reason, it messes up Eclipse when it starts up on a new workspace. I do not have time to figure out why, so for now I need to just revert. Felipe, maybe you can explain why you thought this could break clients in theory... because it does... Maybe something about not having any content yet. Maybe some of the sub-layouts have been given width or height hints and they need to be forced to set them? I think we may have to close this as "won't fix", and give up on speeding up stack layout for now.
Bug 300056 is the Eclipse bug, FYI.
(In reply to comment #10) > For some reason, it messes up Eclipse when it starts up on a new workspace. > I do not have time to figure out why, so for now I need to just revert. You may want to look at our use of StackLayout and let us know if we are using StackLayout in an inappropriate way. If it could be argued that our use is broken, we can probably fix the problem on our side by adding a call to layout somewhere.
>we can probably fix the problem on our side by adding a call to layout >somewhere. If we use it that way then there are most likely also others out there doing it the same way.
I've just filed a bug 318080 where I'm encountering something similar "strange" when it comes to stack layout because when you use it in an scrolled-composite and do a size calculation it also takes the invisible children into account which might be desired under normal circumstances but not in it the above mentioned use case.
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.
