In Jo-Widgets gibt es im Interface IContainer die Methoden !layoutBegin() und
!layoutEnd().
Diese sind für die Implementierung gegen SWT sind diese in !SwtContainer.java
definiert als:
{{{
public void layoutBegin() {
composite.setRedraw(false);
}
}}}
und
{{{
public void layoutEnd() {
composite.layout(true, true);
composite.setRedraw(true);
}
}}}
Zweck dieser Operationen ist (nach meinem Verständnis) bei häufigen
Änderungen von UI Komponenten
ein flackern zu vermeiden (durch das setRedraw(false)).
Ein Performance-Bottleneck kann bei häufigem Aufruf der Methode layoutEnd()
der Aufruf von
composite.layout(true, true) darstellen. Laut SWT Dokumentation bedeuten beide
True Flags,
dass "Brute Force" alles komplett neu layout'ed wird, ohne Optimierung durch
z.B. gecache'te Informationen:
{{{
If the changed argument is true the layout must not rely on any information it
has cached about its children.
If it is false the layout may (potentially) optimize the work it is doing by
assuming that none of the receiver's
children has changed state since the last layout. If the all argument is true
the layout will cascade down through
all child widgets in the receiver's widget tree, regardless of whether the
child has changed size.
}}}
Wird layoutEnd häufig augerufen, kann dies zu einer "Trägheit" der
betroffenen UI Teile führen.
Daher ist layoutBegin und layoutEnd nur dort zu verwenden, wo man sicher sein
kann, dass es selten
aufgerufen wird bzw. wo keine negativen Auswirkungen auf die UI Performance zu
befürchten sind.
Ein Vorschlag für eine API Änderung ist daher, neben der Methode
{{{
void layoutEnd()
}}}
eine weitere
{{{
void layoutEnd(boolean optimise)
}}}
einzuführen. Der Flag optimise gibt an ob auf Optimierungen beim layoutEnd
zurückgegriffen werden kann.