Evaluate performance suggestion of https://bugs.eclipse.org/bugs/show_bug.cgi?id=558392#c16

[vogella]

During debugging I noticed that SashLayout in platform still contains the following code:

else {
			try {
				layoutUpdateInProgress = true;
				adjustWeights(sashesToDrag, e.x, e.y);
				// FIXME SWT Win requires a synchronous layout call to update the UI
				// see https://bugs.eclipse.org/bugs/show_bug.cgi?id=558392
				// once this is fixed, the requestLayout call should be sufficient
				if (Platform.getOS().equals(Platform.OS_WIN32)) {
					try {
						host.setRedraw(false);
						host.layout();
					} finally {
						host.setRedraw(true);
					}
					host.update();
				} else {
					host.requestLayout();
				}
			} finally {
				layoutUpdateInProgress = false;
			}

One untested proposal from https://bugs.eclipse.org/bugs/show_bug.cgi?id=558392#c16 was:

What I noticed is that every `Composite.resizeChildren()` calls its own `DeferWindowPos()`. THis doesn't sound too good, I would expect a significant improvement if everything happened under a single `DeferWindowPos()`.

It looks like this is still the case:

boolean resizeChildren (boolean defer, WINDOWPOS [] pwp) {
	if (pwp == null) return true;
	long hdwp = 0;
	if (defer) {
		hdwp = OS.BeginDeferWindowPos (pwp.length);
		if (hdwp == 0) return false;
	}
	for (WINDOWPOS wp : pwp) {
		if (wp != null) {
			if (defer) {
				hdwp = OS.DeferWindowPos (hdwp, wp.hwnd, 0, wp.x, wp.y, wp.cx, wp.cy, wp.flags);
				if (hdwp == 0) return false;
			} else {
				OS.SetWindowPos (wp.hwnd, 0, wp.x, wp.y, wp.cx, wp.cy, wp.flags);
			}
		}
	}
	if (defer) return OS.EndDeferWindowPos (hdwp);
	return true;
}

@HeikoKlare AFAICT you are familar with SWT Windows part. Does the above suggestion make sense? Would be nice to use deferred layout calls in SashLayout also for Windows.

[HeikoKlare]

I agree that it would be nice to use deferred layout calls in SashLayout for Windows as well. It would make the behavior consistent across different platforms and would also render further tweaks required because of this obsolete, like special handling for embedded windows that had to be introduced to avoid flickering:

• Fix for Flickering in Embedded Apps #1588

I have taken a look into the code of Composite#resizeChildren() and tried to understand the above proposal. The method is used in a quite messy way. The pwp argument is filled with the value of field lwpw that, in turn, is rewritten by child controls (writing parent.lwpw) with a very specific protocol spread and replicated across multiple methods. So in short: this seems to be difficult to understand without either already being an expert in this code or investing quite some time into understanding the code (and in the best case taking the change to refactor it to make it easier for others to understand). Unfortunately, I can currently offer neither of the two.