Community
Participate
Working Groups
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=535978#c14 > We are trying a 4.11 integration build as a base for our product and our > ARTs ran into a hang. Bisection lead to this commit: > > https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=71472c2bbf838e2b785684fd57f0b2db6f2651cd > > If I revert this commit with current SWT master, the hang is gone. > > I've attached a YourKit profile snapshot, I've attached YourKit for some > time during the hang. > > I'll try to reproduce the problem in a minimal snippet, then I'll open a > ticket for it. Or should I re-open this one? So far no luck in reproducing this outside of our product. We have a GEF based view, with some drawn canvas on the left and a property page on the right. Clicking on an editable cell in the property page opens an editor. From that point on we see endless calls to Tree.rendererGetPreferredWidthProc. This results in an endless wait in a few of our ARTs, which wait on display events and jobs after clicking on a cell in order to edit it.
Hi Eric, I'm struggling to reproduce the problem here, so far my SWT/JFace snippets don't ever run into even a single call to Tree.rendererGetPreferredWidthProc(). However I do see this called whenever I e.g. hover over Package Explorer elements, or the cells of a property page (e.g. the Properties View). Unfortunately I don't find any properties that I can edit in the Properties View. I've not been able to use PropertySheet in a snippet (this is what our product uses, albeit somewhat customized), I'll probably need a few days just to understand how to use the underlying framework. Any idea what causes Tree.rendererGetPreferredWidthProc() calls? Must I change some property on the SWT tree? I tried adding an image to the tree element to no avail. Best regards and thanks, Simeon
(In reply to Simeon Andreev from comment #1) > Hi Eric, > > I'm struggling to reproduce the problem here, so far my SWT/JFace snippets > don't ever run into even a single call to > Tree.rendererGetPreferredWidthProc(). > > However I do see this called whenever I e.g. hover over Package Explorer > elements, or the cells of a property page (e.g. the Properties View). > Unfortunately I don't find any properties that I can edit in the Properties > View. > > I've not been able to use PropertySheet in a snippet (this is what our > product uses, albeit somewhat customized), I'll probably need a few days > just to understand how to use the underlying framework. > > Any idea what causes Tree.rendererGetPreferredWidthProc() calls? Must I > change some property on the SWT tree? I tried adding an image to the tree > element to no avail. > > Best regards and thanks, > Simeon GetPreferredWidthProc() is a callback from GTK to query the natural width of a cell. You can probably trigger it using computeSize() on a custom drawn Tree/Table. Not sure if it gets called for a "regular" Tree/Table (i.e. not custom drawn) -- I'd have to dig into the code more. (In reply to Simeon Andreev from comment #0) > So far no luck in reproducing this outside of our product. We have a GEF > based view, with some drawn canvas on the left and a property page on the > right. Clicking on an editable cell in the property page opens an editor. > From that point on we see endless calls to > Tree.rendererGetPreferredWidthProc. Where does this editor open up? Do you mean a tree/table editor? What happens if you remove the neighbouring Canvas?
Created attachment 277454 [details] Snippet to reproduce the problem with. Run and observe endless calls to Tree.rendererGetPreferredWidthProc(). OK, looks like the call is caused by the usage of org.eclipse.jface.viewers.OwnerDrawLabelProvider. With the attached snippet "TestTreeViewer.java" the problem is even worse than our own product, there is no interaction necessary to observe endless calls to Tree.rendererGetPreferredWidthProc(). So far not sure why. Note that I've not adjusted the label provider to actually display the tree elements, that was not necessary to observe the problem.
Thanks for the snippet, I'll take a look.
Here is the precise change that the revert brings, which removes the endless calls: diff --git a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Composite.java b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Composite.java index 8e8dd7009c..b5d2c00b52 100644 --- a/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Composite.java +++ b/bundles/org.eclipse.swt/Eclipse SWT/gtk/org/eclipse/swt/widgets/Composite.java @@ -1464,7 +1464,7 @@ void propagateDraw (long /*int*/ container, long /*int*/ cairo) { * widgets still remaining -- usually only happens when scrolling with the mouse * wheel. See bug 535978. */ - if (noChildDrawing != null) GTK.gtk_widget_queue_draw(handle); + //if (noChildDrawing != null) GTK.gtk_widget_queue_draw(handle); } }
(In reply to Simeon Andreev from comment #5) > Here is the precise change that the revert brings, which removes the endless > calls: > > diff --git a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/widgets/Composite.java > b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/widgets/Composite.java > index 8e8dd7009c..b5d2c00b52 100644 > --- a/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/widgets/Composite.java > +++ b/bundles/org.eclipse.swt/Eclipse > SWT/gtk/org/eclipse/swt/widgets/Composite.java > @@ -1464,7 +1464,7 @@ void propagateDraw (long /*int*/ container, long > /*int*/ cairo) { > * widgets still remaining -- usually only happens when > scrolling with the mouse > * wheel. See bug 535978. > */ > - if (noChildDrawing != null) > GTK.gtk_widget_queue_draw(handle); > + //if (noChildDrawing != null) > GTK.gtk_widget_queue_draw(handle); > } > } Thanks -- I'll look into this right now.
(In reply to Eric Williams from comment #6) > (In reply to Simeon Andreev from comment #5) > > Here is the precise change that the revert brings, which removes the endless > > calls: Cool, thanks Simeon! > Thanks -- I'll look into this right now. Would be great to have patch in the next build :-)
New Gerrit change created: https://git.eclipse.org/r/136320
(In reply to Eclipse Genie from comment #8) > New Gerrit change created: https://git.eclipse.org/r/136320 Simeon/Andrey, please look at this gerrit and confirm that it solves the problems on your end.
Gerrit change https://git.eclipse.org/r/136320 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=1befbecaf4583e81f9dfab38ecc4517fbaf36373
(In reply to Andrey Loskutov from comment #7) > Would be great to have patch in the next build :-) This type of quick turnaround is only possible with your and Simeon's quick and thorough investigation. :) (In reply to Eclipse Genie from comment #10) > Gerrit change https://git.eclipse.org/r/136320 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=1befbecaf4583e81f9dfab38ecc4517fbaf36373 In master now.
Thanks for the fix!
Verified in I20190219-0600.
