Community
Participate
Working Groups
When the workbench window is minimized, the shell gets resized to 0,0. But then all of the parts and editors inside the workbench get resized to 0,0 as well. This is expensive for areas in GEF such as the palette and also HTML editors where wordwrapping and expensive layout calculations must be done for a completely temporary and invisible state. When the workbench is restored, the parts are sized back to their previous size. But for some reason, we getting double WM_SIZE callbacks on our canvas with the sizes being identical. I'm not sure who is at fault there. This is a significant performance problem. If the user has 5 HTML editors open, then there will be 20 expensive layouts when the window is restored to full size (5 editorparts X (editor + palette) X double notification of RESIZE). The workbench window should not layout its children when the shell becomes minimized. When restored, the layout could be suppressed, or optimized so that setting controls to their current bounds does not notifiy RESIZE events.
Moving to SWT. Perhaps they want to consider not posting this resize event. The WorkbenchWindow reacts to events that come from SWT.
Fixed > 20041001
What was the fix? Not sending a resize event, or the Shell doesn't report its size as 0,0?
On all platforms, when a shell is minimized, resize events are delivered and the size is correct.
In that case, in what way is the bug fixed? The bug is a performance problem because all open editors are resized to a size at which they will never be viewed. I don't see how this was ever an SWT issue.
The workbench page needs to special-case this size and avoid laying out.
Nope. You missed the point. On Windows, when a shell was minimized and you resized it while it was minimized, we lost the resize event. This didn't happen on other platforms. No one saw the bug because Windows gave a free resize when the shell was unminimized. We throw that away now. As far as I know, no one needs to change any code.
Using the 1101 nightly build, my Canvas is sized to the following bounds when the workbench is minimized: Rectangle(0, 0, 0, 0) When the workbench is restored, I receive three resize events: Rectangle(0, 0, 603, 676) Rectangle(0, 0, 603, 692) Rectangle(0, 0, 619, 692) The second 2 resize events are because we set the scrollbar visibilities back to false. It would be nice (SN) if we could set both scrollbar's visiblities and receive just one resize event, but we can workaround this.
Here is some test code that WORKSFORME: import org.eclipse.swt.*; import org.eclipse.swt.widgets.*; public class PR_59783 { public static void main(String[] args) { Display display = new Display (); final Shell shell = new Shell (display); shell.setText ("Shell"); final Button button = new Button (shell, SWT.PUSH); shell.addListener(SWT.Resize, new Listener () { public void handleEvent (Event event) { System.out.println ("RESIZE: " + shell.getBounds () + ", " + shell.getClientArea ()); button.setBounds (shell.getClientArea ()); } }); shell.setSize (200, 200); shell.open(); shell.setMinimized (true); System.out.println ("BOUNDS+CLIENT: " + shell.getBounds () + ", " + shell.getClientArea ()); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } }
Steve, you've proved that the client area becomes 0,0, while the bounds remain unchanged. That's good to know. This bug is about the (expensive) resizing of controls inside the shell. There is no reason for the workbench window to layout controls inside an invisible rectangle. So let's start over and fix my first sentence to something like "When the workbench window is minimized, the shell lays-out its children inside an area which is size 0,0".
With XP's ClearType enabled, I get around 620 millis wasted time for a very simple test case. public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); shell.setText("Shell"); final StyledText text = new StyledText(shell, SWT.MULTI | SWT.WRAP); text.setText(System.getProperties().toString() + System.getProperties ()); shell.addListener(SWT.Resize, new Listener() { public void handleEvent(Event event) { System.out.println("RESIZE: " + shell.getBounds() + ", " + shell.getClientArea()); if (shell.getClientArea().isEmpty()) { long start = System.currentTimeMillis(); text.setBounds(shell.getClientArea()); long end = System.currentTimeMillis(); System.out.println("Wasted time:" + (end - start)); } else text.setBounds(shell.getClientArea()); } }); shell.setSize(200, 200); shell.open(); shell.setMinimized(true); System.out.println("BOUNDS+CLIENT: " + shell.getBounds() + ", " + shell.getClientArea()); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
Results on my XP box show the client area is not (0, 0). It should be the same whether the shell is minimized or not. Here they are: RESIZE: Rectangle {154, 203, 200, 200}, Rectangle {0, 0, 192, 166} BOUNDS+CLIENT: Rectangle {154, 203, 200, 200}, Rectangle {0, 0, 192, 166}
SN, did you mean to type "20041001"? I'm using 1101 and see 0,0 on XP.
I meant "Fixed > 20041101". Typo on the month number.
It may have been released to CVS on 1101, but it was not in the 1101 nightly build. I've verified the fix on 1103 build.
"when a shell is minimized, resize events are delivered" was also confusing, because of the missing "not" ;-)
Reopening.
Randy, could you explain why changed both the component and owner? A little context, please?
When the workbench window is maximized, and you minimize it, it gets "restored" first, meaning it is resized to its non-maximized size. The entire workbench lays out, which is wasteful since the shell is never visible at that size. When you un-minimize the window, you get another extra layout. The performance hit is multiplied by the number of editors and pages that are open. If the window is not maximized, there is no resize or laying out and thus no performance problem.
The original description is still somewhat accurate, except instead of things getting sized to 0,0, the shell gets sized to its non-maximized width and height and lays out. For anything whose layout is width-sensitive, such as an HTML page, or simply a wrapped paragraph of text, the extra layouts can cause the workbench to appear very slugish when being re-maximized.
There are currently no plans to work on this although we would be happy to review a patch
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.
