Bugzilla – Full Text Bug Listing
| Summary: | Some widgets not repainting (on some systems) | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Gary Karasiuk <karasiuk> | ||||
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> | ||||
| Status: | CLOSED NOT_ECLIPSE | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | eclipse.felipe, remy.suen, tjbishop | ||||
| Version: | 3.6.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Gary Karasiuk
Sorry Gary, we do not have enough information to start investigating your problem. Based on your description it sounds like there is too much processing happening in the UI thread (the UI thread is too busy and can't processes paints messages fast enough) - this usually means a bug in the application code (UI thread is doing work that should be done in background threads). Please reopen this problem if you find more information that can help us to reprduce the problem here. I don't think that the problem is the UI thread being busy. The CPU is idle while the window is still not repainting. It has other odd symptoms as well. If we start the product from a development environment the problem does not occur. Although we can start it with remote debug enabled, and the problem does occur. I tried turning on these debug options: org.eclipse.ui/debug=true org.eclipse.ui/debug/swtdebug=true org.eclipse.ui/debug/swtdebugglobal=true but nothing interesting was written to the log. To me it seems like the Windows events are not being dispatched to the Windows Controls. (In reply to comment #1) > ... if you find more information that can help us to > reprduce the problem here. What kind of information would you like? (In reply to comment #3) > What kind of information would you like? a) a testcase that shows the bug b) stacktraces c) set of steps (using eclipse) that trigger the bug (In reply to comment #2) > I don't think that the problem is the UI thread being busy. The CPU is idle > while the window is still not repainting. what about other events ? is the window responding to key or mouse events ? > To me it seems like the Windows events are not being dispatched to the Windows > Controls. is it the entire window that is not painting or only part of it ? the events are not dispatched when the ui thread does not run the event loop, if the UI thread is not busy then maybe it is waiting on a lock. can you debug eclipse (self host) and stop the ui thread when the problem happens ? that will show as what the ui thread is doing. This is getting even more bizarre. I was doing my original testing on a remote system, using Window's remote desktop feature. I went to the system that was having the problem, and accessed it locally. When accessed locally, there is no problem. I went back and connected via remote desktop and the problem reoccurred. This problem only happens with this one modal dialog, and it only effects the Main Eclipse Window. (i.e. all the Windows that I have open, Firefox, Explorer, .., are working correctly. (In reply to comment #5) > (In reply to comment #2) > > I don't think that the problem is the UI thread being busy. The CPU is idle > > while the window is still not repainting. > > what about other events ? > is the window responding to key or mouse events ? The modal dialog is responding to other mouse events. The main Eclipse Window is not responding to anything. > > > To me it seems like the Windows events are not being dispatched to the Windows > > Controls. > > is it the entire window that is not painting or only part of it ? The title and the menu bar still repaint, the rest of the Window does not repaint. I will attach an example screen shot, where I moved the modal dialog around a bit. > > the events are not dispatched when the ui thread does not run the event loop, > if the UI thread is not busy then maybe it is waiting on a lock. > > can you debug eclipse (self host) and stop the ui thread when the problem > happens ? that will show as what the ui thread is doing. The stack trace that I added to the description is while the problem is occurring. It shows that the UI thread in the normal state of waiting for the next event. i.e. OS.WaitMessage(Native Method) Created attachment 192094 [details]
screenshot
I was able to take the bundles for this dialog (there were only 8 of them), and install them into Eclipse 3.6.2. The problem still occurs when viewing Eclipse through a Windows Remote Desktop. Felipe, given that this is a remote desktop problem only, is this still something that you want to pursue? It may be a Windows bug, but it seems odd that I am only hitting this problem with this one dialog. The other dialogs that I tried (like New Project Wizard) are fine. The developer of the dialog fixed a problem, and the repainting problem has now been fixed. If you would like you can close this defect, or if you would like to investigate how a dialog change could affect repainting only when running a remote desktop, I could try to get you the before and after dialog plug-ins. Thank you for the update Gary, I would like to know what he was doing wrong but mostly for my curiosity at this point. (In reply to comment #11) > Thank you for the update Gary, I would like to know what he was doing wrong but > mostly for my curiosity at this point. I was populating a tree (via a content provider implementing org.eclipse.jface.viewers.ILazyTreeContentProvider) which ended up showing duplicate nodes (i.e. each node in the tree was, incorrectly, added twice). I'm not sure how that caused the repainting problem that Gary was experiencing. |