Community
Participate
Working Groups
See the attached screenshot. When the editor was revealed, I think from closing some other editor, it did not paint properly. This is "forms" editor, like some of the PDE editors in eclipse. It does not use GEF.
Things eventually paint normally if you: 1) switch to some other editor and come back 2) if you resize the editorpane
Created attachment 191226 [details] Screenshot
As Randy pointed out, #353459 could be related to this as well. It allows to easily reproduce the issue with the GEF logic example editor.
If have the same redraw problems with my property views on Mac OS. No labels and borders are painted, only the StyledText widget is painted correct.
Created attachment 205510 [details] Defect property pages
The dependent GEF bug #342445 (which seems to be caused by this one) is a really ugly thing. Could you investigate this one for 3.7.2?
Created attachment 206559 [details] Eclipse plug-in exhibiting some painting issues I'm not sure if this is the same bug ("SWT Painting problems in Cocoa" is pretty broad), but I'm having similar painting problems on Cocoa in a UI Forms multi-tab FormEditor (large unpainted areas). I've attached source code for a very minimalistic FormEditor that demonstrates the problem. This editor contains three copies of a FormPage containing a Button and a Tree: 1. The first (default active) page always renders correctly. It uses an AbstractColumnLayout (specifically, TreeColumnLayout, but I've had the same problem with TableColumnLayout). 2. The second page is the same as the first. The first switch to this page exhibits painting problems (only the Tree is painted; the Button and the FormPage background remain gray). Subsequent switches work correctly. FormPage creates its controls lazily, which may be relevant. 3. The third page is the same as the second, except it uses a FillLayout instead of an AbstractColumnLayout. It always paints correctly. I cut and paste the AbstractColumnLayout source code, and tried commenting different chunks of code. When I commented out the "scrollable.update()" line in layoutTableTree(), I no longer had the painting issue. (I don't recall if I had some other issue instead.) The platform I've tested this on is Eclipse 3.7.1 on Mac OS X 10.7.2. I haven't tested other versions of Eclipse or Mac OS X. I'm not having any painting issues on Windows XP SP3, which is the other platform I've tested on.
Just wanted to add a "me too". I've observed form painting issues whenever a table incorporates TableColumnLayout. Problem appears to be specific to Mac OS 10.7 or greater
Felipe, this is kind of an ugly thing. Could you give some comment about what we can expect for 3.7.2 w.r.t. this?
This problem is also affecting Mylyn and is causing loss of functionality. I have raised the severity to major to reflect that this has a significant effect on the user experience.
Why change the version to 3.7.1? This problem was reported against 3.6. It probably exists in every release, but Cocoa wasn't really supported until 3.6. Changing the version to 3.7.1 suggests that it is a recent regression.
"me too" - our product is having some repaint issues that appear to have begun with the 3.7-era (in our case, we don't have reports on our 3.6-based releases)... I'll attach a screenshot of what we are having reported; large areas of stuff not painting; the view being shown is a custom "property" view that uses FormToolkit extensively, CTabFolders, sashes...
Created attachment 214394 [details] screenshot of rendering issue under OSX the visible painted stuff on the left is a table (that has cell editors, custom focus painter, etc.). Missing are Sections (a collapsed one above, an expanded one hosting the table you see peeking through), the tabs from a CTabFolder above it, and a white composite area above that. The table also has a toolbar above it to the right, missing.
I'll also add the following (as I've locally reproduced the issue in a dev environment) -- when the mouse is hovered over the gray-area, the cursor is reponding (shows a hand cursor for hyperlinks for example). Might be useful info.
We've had users report this against Eclipse 3.7.1. I just reproduced in a dev workspace using Eclipse 3.7.2. OSX 10.7.3 Our table has a TableColumnLayout
I see same on Eclipse 3.7 & Mac 10.6. We have a Tree with TreeColumnLayout inside of ViewPart. Somehow I managed to make it display correctly for the first time (adding some .layout() calls.. removing others), but it still lags as on screenshots when view is resized.
Sure would be nice to see this fixed. The workaround of resizing the workbench every time this happens is getting old.
(In reply to comment #8) > Just wanted to add a "me too". I've observed form painting issues whenever a > table incorporates TableColumnLayout. Problem appears to be specific to Mac OS > 10.7 or greater I've seen this problem since 10.5. It's been in every release of SWT for Cocoa.
Here's another "me too." I see the same as reported by Andreas (Comment 4) in our RCP app (OS X 10.7, Eclipse 3.7.0). There is a lot of interest in this bug. To someone on the Platform team, how do we move forward from here?
Created attachment 214965 [details] patch against master (4.2 branch) This patch fixes the problem in comment#7. I am not sure it will fix every problem reported here, since I have never been able to reproduce this using plain Eclipse SDK. I will release it in 3.8/4.2 RC1. I would appreciate if any one could give it a try.
Silenio, would I be able to simply drop the 3.8 SWT bundle and fragment into eclipse 3.6? That would be the easiest way (for me) to verify that your change (vs. all the other 3.7 and 3.8 changes) fix the problem. I can reproduce it 100% of the time.
I have released the patch to master (4.2) and R3_8_maintenance (3.8). Please reopen if the problem can still be reproduce in Eclipse 3.8/4.2 RC1. Fixed http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=642c17db34aa58b5ab4b480578f048d3f7457d64 http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=229332375853b918e604832dc3f22ca6f2caf890
(In reply to comment #21) > Silenio, would I be able to simply drop the 3.8 SWT bundle and fragment into > eclipse 3.6? That would be the easiest way (for me) to verify that your change > (vs. all the other 3.7 and 3.8 changes) fix the problem. I can reproduce it > 100% of the time. I do not think this is possible anymore. I believe p2 does not allow it.
(In reply to comment #23) > > I do not think this is possible anymore. I believe p2 does not allow it. You would have to feature-patch it in, but p2/the SDK should allow it. PW
(In reply to comment #22) > I have released the patch to master (4.2) and R3_8_maintenance (3.8). Please > reopen if the problem can still be reproduce in Eclipse 3.8/4.2 RC1. > > Fixed > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=642c17db34aa58b5ab4b480578f048d3f7457d64 > > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?h=R3_8_maintenance&id=229332375853b918e604832dc3f22ca6f2caf890 Well, I would really like to validate that our related GEF issue is resolved. However, I am not able to locate any nightly platform/swt builds anywhere, neither on hudson.eclipse.org nor on downloads.eclipse.org. Where can I find them nowadays?
This build contains the fix: http://www.eclipse.org/downloads/download.php?file=/eclipse/downloads/drops/I20120510-2100/eclipse-SDK-I20120510-2100-macosx-cocoa.tar.gz
I can confirm that this issue is fixed for me in the above build.
I can also confirm that my issue (comment #7) has been fixed. Thanks!
Silenio, is there a workaround that be used on older Cocoa implementations to get the Composite to paint when this problem occurs? What was the actual problem? If there's no such workaround, maybe there's a way to avoid doing whatever causes it to occur?
Randy, I got rid of Tree/TableColumnLayout in favor of simple TableLayout, that helped me.
(In reply to comment #29) > Silenio, > > is there a workaround that be used on older Cocoa implementations to get the > Composite to paint when this problem occurs? What was the actual problem? If > there's no such workaround, maybe there's a way to avoid doing whatever causes > it to occur? The problem happens when Control.update() is called from a SWT.Resize event handler, ControlListener.controlResize() event handler or from implementations Layout.layout(Composite, boolean). The only workaround I can think of is to stop calling Control.update() from those methods.
