Skip to content

Feature Request: layoutEnd(boolean optimise) #27

@GoogleCodeExporter

Description

@GoogleCodeExporter
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. 


Original issue reported on code.google.com by [email protected] on 18 Jan 2013 at 9:49

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions