Bugzilla – Full Text Bug Listing
| Summary: | Workbench window rendering very slow when restored from minimized state if previously maximized | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ben Roling <rollsisu> |
| Component: | SWT | Assignee: | Bogdan Gheorghe <gheorghe> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | frydzewski, gheorghe, jfordham, ob1.eclipse, remy.suen, sarah.brake, Silenio_Quarti |
| Version: | 4.2 | ||
| Target Milestone: | 4.2 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 407043 | ||
| Attachments: | |||
|
Description
Ben Roling
Created attachment 201743 [details]
screencast demonstrating issue
Ben, thanks for the screencast. First question is whether the truly ugly Black flashing is something you see or is it an artifact of the capture code ? I've tried looking a the AVI file with both WMP and QuickTime. I've just come back from a trip to the SWT lab and our Windows 7 boxes don't seem to be exhibiting this behavior. If you really are seeing the black uglish-ness the best guess is that is may be a driver issue, do non-eclipse apps show the same behavior ? For a basic test here's a link to a simple SWT snippet to test whether it's an eclipse, SWT or system issue... http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet1.java Thanks for the quick response Eric. One point I should have clarified is that my desktop background was completely black for the video. I maybe should have chosen a different color or something but I wanted a solid color to try to keep the video size down. I do see ugly black areas inside the app window as it is restoring however. The areas appear black even when my desktop background is a different color (like red for example). Non-eclipse apps do not exhibit this behavior. I even wondered if maybe it was a general Java app thing, but I don't have any non-Eclipse apps (java or otherwise) that do this. I use Oracle SQL Developer (java app) and it doesn't do this. No native Windows app I have ever seen does this. Any web browser (Firefox, Chrome, IE) doesn't do this. They all minimize and restore very quickly without any weird rendering artifacts. Just in case my system configuration is of interest, I am running this on a Lenovo W510 laptop: Intel Core i7 Processor 4GB Ram (with plenty free) Windows 7 Enterprise (64bit) NVIDIA Quadro FX 880M display adapter You may already understand, but my concern isn't so much how the areas are an ugly black color, but more so how long it is taking to complete the rendering. As it is re-rendering it looks as if things are re-sizing several times. You might not be able to see that so well from the video due to the low frame rate (10 or 15 fps). The snippet you have provided doesn't exhibit the issue. It renders quickly on restore. With respect to hardware, I should also note that I saw this same slow rendering on the Dell E6500 I had before this Lenovo. It's pretty interesting that you don't see this in your lab though. Would you say restoring from minimize after maximize is just as fast for you as if the window weren't maximized first? Or does it still take a bit of time to render, but just looks smoother? Another point of clarification: There seems to be substantially more CPU activity from the java process running Eclipse on restore from minimize after maximize vs without maximize. Well, I just tried this on my home PC and it restores much quicker. Interesting... For reference, my home PC is an HP Pavillion desktop with the following configuration: Windows Vista Home Premium (64-bit) Intel Core2 Quad Q6600 processor 4GB Ram ATI Radeon HD 5670 display adapter I'm pretty sure other people at the office are seeing this same thing but they would have the same (or very nearly the same) device configuration as I do. Maybe there is something about the device configuration that plays into it. I will be out of the office tomorrow but when I get back on Monday I will try to do a few more tests and see if I can try one or more other devices. Ben, could you also check to see if there are any driver upgrades available for your graphics card ? Also, what is the effect of running the snipped supplied in comment #2 ? (In reply to comment #3) > Just in case my system configuration is of interest, I am running this on a > Lenovo W510 laptop: > > Intel Core i7 Processor > 4GB Ram (with plenty free) > Windows 7 Enterprise (64bit) > NVIDIA Quadro FX 880M display adapter > I have the same laptop (Lenovo W510 with Nvidia FX880M) and do not see anything even close, with or without Aero. (In reply to comment #8) > (In reply to comment #3) > > Just in case my system configuration is of interest, I am running this on a > > Lenovo W510 laptop: > > > > Intel Core i7 Processor > > 4GB Ram (with plenty free) > > Windows 7 Enterprise (64bit) > > NVIDIA Quadro FX 880M display adapter > > > > I have the same laptop (Lenovo W510 with Nvidia FX880M) and do not see anything > even close, with or without Aero. Actually, let me take that back. I see similar effect (not as pronounced as in the video, about 2x - 4x faster) if I switch off Aero and use black background. If either another app is on screen (making background non-black) or Aero is on, I can see the effect in the video. Funny thing, now that I started to look for it, Windows control panel seems to be jumpy too when I maximize it... The effect is similar in both Eclipse 3.7 and 4.1. I'll pass this off to SWT on the off-chance that they see something that can be fixed. (In reply to comment #6) > Ben, could you also check to see if there are any driver upgrades available for > your graphics card ? Yes, there are updates available for my graphics card. I am running driver version 8.17.12.5738 from 6/27/2010 and there is a new version 8.17.12.6824 with date 8/9/2011 that I have not tried yet. I didn't want to mess with that until I did a little more investigation of other variables. (In reply to comment #7) > Also, what is the effect of running the snipped supplied in comment #2 ? You probably missed this in comment #3, but the snippet does NOT exhibit the issue. Today I also tested rebooting my laptop and I found that the render time was much faster afterwards. I even closed all open applications before resorting to this and it was still slow so I don't know what exactly it is about reboot that had this effect. I only very rarely reboot - I almost always suspend/sleep and resume instead of shutdown. I just thought I would give it a shot anyway to see if it made any difference. For comparison though I probably haven't rebooted the desktop machine at home in months either although it gets significantly less continuous use if that really makes any difference. I also tested using the "Windows 7 Basic" theme vs the "Windows 7" Aero theme and did notice that with the basic theme I don't see the ugly black boxes during the rendering and it seems quicker. I've done some more investigation of this issue. I agree it is an SWT issue rather than a Platform UI issue. I can recreate the issue with a pure SWT program. The issue is much more dramatic in the application I am working on. When in some parts of the application it can take as long as 6 seconds for the UI to render when restored from minimized state if the window was maximized. If the window wasn't maximized it will render quickly (~250ms). I can't share the code for this application and even if I could you probably wouldn't want to look at it because it is too complex. I tried a bit to come up with a simple SWT snippet that demonstrates the issue. What I came up with demonstrates the issue to a much less degree than in my real application and is not representative of the UI of the real application but it is difficult to translate a real application into a simple snippet. Along with the SWT snippet, I also mimicked the SWT snippet in Swing and C# (WPF). Neither the Swing nor the WPF snippets have any minimize/restore problem like the SWT snippet. I know Swing is dramatically different than SWT in its implementation and WPF probably is too. When I did the WPF snippet I really wanted to do something Windows native that would serve as a good comparison and I would have used more primitive Windows APIs but unfortunately it's been a long time since I've done that sort of programming and I didn't have time to re-learn it to try to come up with an example. Maybe that is trivial for someone else to do. A couple things I noticed about the SWT snippet: - It seems to take 1-2 seconds to re-render from minimized on my W510 laptop with Aero theme. It seems sometimes it is a bit faster without Aero. The way it renders is definitely different without Aero. I don't see a bunch of black rectangle rendering artifacts without Aero. I do sometimes see it slow without Aero though. It just doesn't render right away and then all of a sudden everything pops in at the end vs with Aero where you see things (black rectangles) happening during the whole rendering time. - In the snippet I am using a GridLayout with spacing of (5,5). If I set the spacing to (0,0) the rendering is noticeably faster. I will be attaching the snippets shortly. Created attachment 202235 [details]
SWT snippet demonstrating rendering issue
Created attachment 202236 [details]
Swing snippet mimicking SWT snippet - Swing snippet has no rendering issue
Created attachment 202239 [details]
zip containing visual studio project files, source and .exe for simple WPF application similar to SWT snippet - has no rendering issues like SWT snippet
A key difference I have noticed between minimize/restore from a maximized state vs a non-maximized state is that minimize/restore from a maximized state causes the Shell's Layout.layout() to be invoked. Minimize/restore from a non-minimized state does not invoke the layout at all. I suspect it is the re-layout that is causing the issue. Interesting when the window is maximized, layout() is invoked both when the window is minimized and again when it is restored. If the window is not maximized, layout() is not called on either minimize or restore. I wonder why layout() is involved here. Maybe to support the case where the app is minimized, the screen resolution is changed, and then the window is restored? This way it would still consume the whole screen and be laid out appropriately? Maybe there is some optimization that can be made such that this re-layout does not occur unless really necessary? (In reply to comment #11) > (In reply to comment #6) > > Ben, could you also check to see if there are any driver upgrades available for > > your graphics card ? > > Yes, there are updates available for my graphics card. I am running driver > version 8.17.12.5738 from 6/27/2010 and there is a new version 8.17.12.6824 > with date 8/9/2011 that I have not tried yet. I didn't want to mess with that > until I did a little more investigation of other variables. I don't think it really matters anymore, but to be perfectly clear I did also update to the latest version of the display driver and it doesn't make any difference. I'm pretty sure it's not a display driver issue. Stepping through this in the debugger it seems the problem relates to org.eclipse.swt.widgets.Decorations.WM_SIZE(). This method tries to detect size changes based on WM_SIZE events and seems to incorrectly detect a change when minimized and restored from a maximized state. When minimized, WM_SIZE() calls getClientArea() to determine the new size. When the window is being minimized from a maximized state, the getClientArea() call returns a size that is different than the window's maximized size. As a result, WM_SIZE() decides there has been a size change and ultimately the layout is triggered. Then again when the window is maximized getClientArea() returns the maximized size, which is different than the 'old' size which was returned when getClientArea() was called on minimize and the layout is triggered again. When minimized and restored from a non-maximized state, the getClientArea() call returns the same size during Decorations.WM_SIZE() calls for both the MINIMIZED and RESTORED size events. With the keyword of WM_SIZE I was able to find bug 59783, which I guess is basically the same thing. Created attachment 202254 [details]
patch that seems to resolve the issue
I'm sure I've not tested this patch thoroughly enough, but in the brief testing I have done it seems to work.
Can somebody take a look? I deleted a bunch of lines that I have to assume were there for a reason that I don't understand. This patch is probably too simple but maybe it will spur some other ideas.
I'd really like to get to some resolution of this issue because it has a pretty profound effect on applications where the layout is expensive.
Thanks for investigating this and for your patch. You are absolutely correct in your analysis - the call to GetWindowPlacement in getClientArea is not returning the correct size. We need to investigate some more to see where else our current code could be wrong (as we use it other places). We also need to think a bit more to see if there are any other problems that might come up from returning the old width and height as you do in your patch. I'm targeting this for M2. Thanks Bogdan! I'm glad to see someone taking interest in this. I expect a lot of people will be pleasantly surprised when this issue is fixed. Please review target milestone and bump to > 4.2 if appropriate. Not sure why this wasn't closed ages ago (in M2). Here is the commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1ee8264f8e285fb6512cc29b5bbd3dd0b51e73f5 |