Community
Participate
Working Groups
I20070306-1200 Maximize/Restore (Ctrl+M) of workbench parts is too slow in the 3.3 presentation. E.g. maximizing the Outline already takes more than half a second in the default Debug perspective (without additional views). I could live with having fast view bars appear with a delay, but the target part should be maximized instantaneously.
Markus, is this a 'first time' issue? If you maximize it once, restore and then maximize again is the performance on the second max fast enough? I ask because I've just fixed a defect that was aggressively loading the plug-ins for the views associated with every tab in the presentation. See Bug 176408 for details...
No, I "measured" the >500ms by repeatedly pressing Ctrl+M and counting how many times I could maximize and restore the part in 10 seconds.
Got you...just tried the same tests myself. The current code hasn't been tuned -at all- yet for performance; right now the focus is on stability and ensuring that it handles everything (including edge conditions like the Intro and minimizing the currently maximized stack) 'sensibly'. This work is winding down so I should have time to do some tuning soon. I'd expect that I can cut this in half (at least) but I it'll never be as fast as the current version....just a -lot- more useful...;-)
Sure, I have no problem with that as long as the plan is a Target Milestone of 3.3 ;-). I really like the new functionality, but the current price is too high for me.
*** Bug 181250 has been marked as a duplicate of this bug. ***
Markus, I'm out of cycles. The performance is as good as I've had time to make it. Unless input comes from the community at large (very few complaints have come in) I'm going to defer further optimizations to post 3.3.
I just tried this for the first time on 3.3RC4, and it's still very noticeable. I can imagine me and my RCP users getting a lot of stress from this feature that is used all the time.
I'm still finding it a bit too slow too, for reasons described on bug 181250, so I now tend to use perspectives to get a maximized editor area (although when I'm willing to take the hit I love the new trim). A big part of the problem appears to be the fact that the whole page goes gray while the editor disappears. I think that this is very disruptive visually, and makes the maximization seem a lot slower and worse than it is. In contrast, when perspectives are switched the editor area appears to persist because it is not appear to be redrawn when the switch is initiated. This was also the behavior on 3.2. So I wonder if the current problem could be improved by controlling the redraw during the animation?
Mik, we have tried an animation techique that does a good job of hiding -all- the flicker while major display changes (i.e. zoom) take place. Unfortunately it is in itself soemwhat of a cycle hog (it takes a screen cap of the current window and then covers it with an animation frame whose background is the captured image). We're in a bit of a catch-22 here. The current behavior already has the animations completely independent of the actual presentation's update (i.e. you should see the new presentation -before- the animation even starts). How does it 'feel' if you turn off anmations? I' mwondering if it's making the operation seem heavier that it actually is...
It looks no better if I turn off the animation for the reason that you describe: the animations are independent and not the problem. I now think that the majority of the perceived problem is the fact that such a big part of the screen goes gray (on Windows). It goes gray for a long enough time that our visual system notices the change and registers everything as having disappeared, then shortly thereafter we notice everything reappear. I bet that if the maximization happened at the same speed but without the graying out it would not appear to be nearly as slow. I don't see any problem with making the CPU spike due to the 500ms or however long it takes to maximize since it is impossible for the user to interact with the workbench during that time. So I like the screen cap approach. The only other thing I can think of is disabling the redraw of the workbench shell and doing the animations in separate shell(s) somehow, but that might go back to the screen cap idea. Or perhaps you could make the animation only draw themselves on parts that are over the editor area, leveraging the fact that the editor area is what's most frequently maximized and is typically surrounded by views?
Mik, I've run this on as many windows boxes as I can get to but don't ever see the editor area go 'gray'. I already have a setRedraw(false) and a 'deferUpdates' wrapping the operation. What editor is open (I'm thinking perhaps it has a long update cycle when its container changes size)?
(In reply to comment #11) I also don't see a grayed editor area with the editors I commonly use (text, Java, compare, PDE manifest). What I see however, is that each view seems to be minimized individually, making the FVBs flicker and redraw repeatedly.
Oh drat, I'm so sorry for not being more specific, this is a *Vista only* thing and as you point out does not happen on XP or Linux. I have not noticed many discrepancies of this sort between XP and Vista and so I failed to realize that this could be the problem. So all of the "visual disruption" stuff I mentioned does not apply to XP (I just tried it a bunch), only Vista. In my mind that definitely reduces the severity of this issue. Fyi this behavior happens when running the standard SDK on Vista, not WPF (with WPF I did not see the graying out, but note that the animations are a bit wird).
Ah, the fog clears...;-). So we're talking Vista / non-WPF only. Steve, this sounds like it might be SWT (since the difference is only on this one platform/theme...comments?
Ok, someone needs to find me and show me. I might have some ideas.
Steve, I can try to set up the repro steps since I have a Vista box. However, teh next few days have me doing our spring 'bug sweep' so if I don't get back right away ping me please.
I am having a similar problem on my Windows XP SP2 machine, pressing CTRL+M to maximize/restore any view takes up to one second, with my CPU (one of the cores) spiking at 100% CPU Load. This is a huge difference to Eclipse 3.2 where I never had these issues. The UI first minimizes the left screen area to a button bar (fast view), which is drawn over the rest of the currently visible window, the maximizes the view. This is really disrupting as I am used to quickly switch in and out of maximized editors. I turned off animations, which does not make a difference in the performance.
I think I can speed it up somewhat (2x -maybe-) but I can't match the old method for performance (since it doesn't really do anything...;-). The theory behind the new tachnique is that it supports workflows in which you don't -need- to restore ('un-maximize') from the zoomed state as often. I'll take a look for 3.3.x.
Well, I took a look but any significant optimization will require some fairly deep cahnges in the presentation code (I'd tried this early in the game in 3.3 but ran into sticky issues... Moving to 3.4.
Do we need a Vista specific bug to address the (Vista only) problem described in comment#8?
No, once I start my 3.4 work (I'm currently finishing up on 3.3.1 defects) I'll be reviewing all the defects marked for 3.4 so your comment will be enough to kick me into gear (I already have a Vista box...;-).
It's now about as good as I can make it without a re-write (i.e. e4).
Looks good enough to me. Maximize works great. At the start of minimize I see a flicker where the window goes all gray, but it reappears quickly enough.
Cool, thanks Mik!
