How expensive are control size computations?

[laeubi]

I recently noted that a large part of complexity in layouts is because of caching computed size of children.
Even worse, it sometimes leads to wrong/bad looking layouts (e.g. when wrapping is involved) and one has to install listeners to update or force layouts e.g. there are > 200 calls in platform to org.eclipse.swt.widgets.Composite.layout() even though it is "discouraged" to call this method. I most prominent noted that with SashForm that uses layout(false) leading to components being cut-off instead of wrapped in certain layout combinations, because if a previously (non wrapped) size was cached.

That said, I wonder how expensive (today) computing the size of a component actually is and we may be able to just throw away the caching given that often flushing the cache is enforced and if not it causes problems in some situations.

[laeubi]

Just in case that calling the native methods might be a bottleneck, it might be even better to cache some size in the Widget e.g. just as an example if I take a Button widget it might compute its size once with a native call to get the preferred height/width only once and clear that cached value whenever the text changes, similar for a Label.

[niraj-modi]

I recently noted that a large part of complexity in layouts is because of caching computed size of children. Even worse, it sometimes leads to wrong/bad looking layouts (e.g. when wrapping is involved) and one has to install listeners to update or force layouts e.g. there are > 200 calls in platform to org.eclipse.swt.widgets.Composite.layout() even though it is "discouraged" to call this method. I most prominent noted that with SashForm that uses layout(false) leading to components being cut-off instead of wrapped in certain layout combinations, because if a previously (non wrapped) size was cached.

Please capture the SashForm problem as an issue, and let's check if it works better with UN-cached sizes.

That said, I wonder how expensive (today) computing the size of a component actually is and we may be able to just throw away the caching given that often flushing the cache is enforced and if not it causes problems in some situations.

See caching comes with a trade-off and it should be re-validated when needed, other-wise we may see issues.
Experimentation on these lines can be done case to case basis, but only after 4.24 is release.

[laeubi]

@niraj-modi its more to capture some infos here not that i think SashForm is 'wrong' (most probably not), but maybe someone has a concrete idea or case where caching has improved things in that area, e.g. the Control#computeSize already allows caching of values but this is only used in org.eclipse.e4.ui.widgets.ImageBasedFrame.computeSize(int, int) but nowhere else (at least checking with GTK), so the caching is only done in the Layout managers (where it is actually a bad place as a LayoutManger can not know if any internal widget state might significantly changes a control).