Community
Participate
Working Groups
When a Label widget is in a parent that has its background explicitly set, scrolling the parent in a ScrolledComposite can cause the label to only partially repaint (sometimes it goes away completely). To reproduce: 1) Check out org.eclipse.ui.forms and org.eclipse.ui.forms.examples from HEAD 2) Launch second Eclipse instance 3) Customize perspective so that 'Form Editors' menu shows up on the menu bar 4) Launch the Simple Form Editor and switch to Flow page 5) Scroll the page vertically. Observe how some labels in sections flicker and partially go away while scrolling. I tried to figure out the reason and so far found out that it has to do wih the background painting of the parent. To confirm, open 'Section.java' in org.eclipse.ui.forms.widgets package and comment out the method 'onPaint' (this method paints the blue section behind the section label). You will notice that the problem stops. Similar problem has been noticed with cheat sheets. They too use the same base class (expandable composite) and set the background to explicit color object. As cheat sheet sections expand, collapse and otherwise layout, some portions of the text go away. There is no rhyme or reason to this - it is completely random. This is a serious problem becuase it affects all the sections in all the PDE multi-page editors on GTK. In addition, it affects cheat sheets.
*** Bug 63409 has been marked as a duplicate of this bug. ***
*** Bug 67160 has been marked as a duplicate of this bug. ***
The problem is because of Label.computeSize() called in the paint event. Any comments Steve?
There is a problem on GTK when a resize occurs within a paint. In Label.computeSize, in order to get the size right with wrapping, the size of the Label is temporarily changed to the size of the wHint and hHint and then changed back. Any change to Label.computeSize will have a major effect on Eclipse and this is too risky at this point in the schedule. However, looking at the code in Section.onPaint, it is not clear why textLabel.computeSize is being called. In ExpandableLayout of ExpandableComposite, the size of the textLabel has already been calculated and setBounds has been called. Since the resize event will happen before the paint event, why doesn't Section.onPaint just call textLabel.getSize() rather than textLabel.computeSize? Calling getSize() rather than computeSize() will get rid of this problem and will also be more accurate since the sizing calculation code will not be duplicated.
The relative order of calls was something I didn't know about and therefore could not count on. We will try the workaround and see if it works for us.
VI, do you have a simple testcase for this problem ? Do we know exactly what goes wrong when calling computeSize from a paint callback ? During my tests I could verify the always computeSize returns the right value.
Moving to Eclipse Forms to address in RC4 time frame.
Their still seems to be a bug on SWT somewhere. You shouldn't get the cheese (or at least you should get the same cheese on every platform).
Once we verify that using 'getSize' works for us, I will re-route the bug back to SWT to address post 3.0.
Created attachment 12590 [details] The fix to use 'getSize' instead of 'computeSize'
We confirmed that the patch addresses the vanishing on our Linux machine.
Patch applied and released.
