Summary: | [Workbench] WorkbenchParts resized when maximized Shell is minimized | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Randy Hudson <hudsonr> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | normal | ||
Priority: | P5 | CC: | eclipse, kehn, ppshah, sorensm, steve_northover |
Version: | 3.0 | Keywords: | helpwanted, performance |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Randy Hudson
2004-04-23 10:20:50 EDT
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. |