sizer relative efficiency

One might presume that a wx.GridSizer with one column would be
somewhat less efficient (by some metric, speed or memory use or
both) than a wx.BoxSizer in vertical orientation. One might also
presume that a wx.FlexGridSizer with no growable columns or rows
would be somewhat less efficient than an equivalent wx.GridSizer.
Are these presumptions true, and if so, are the differences in
efficiency of any real significance, especially if one intends to
use multiply nested sizers?

In automating the use of sizers, my preliminary experiments seem to
indicate that the differences in relative efficiency of these
sizers is negligible, but I wonder if I am missing something. If
not, I am tempted just to build multiply nested wx.FlexGridSizers
regardless of whether or not all the features are needed in every
case.

Donnal Walter
Arkansas Children's Hospital

Maybe I can have my cake and eat it too. What I am trying to do is
automate the setup of the sizers for any composite presenter (such
as a frame or panel). The following code seems to do the "Right
Thing" depending on the parameters supplied:

class Subpanel(Presenter):
    """Compostite presenter"""
    cols = 1 # default is a vertical box
    rows = 0
    vgap = 0
    hgap = 0
    growRows =
    growCols =
    text = None # any value adds a StaticBox and SBSizer

    def __init__(self, parent=None, name='', *args, **kwds):
        """Initialize the presenter."""
        Presenter.__init__(self, parent, name, *args, **kwds)

        if self.rows == 1 and self.cols != 1:
            orientation = wx.HORIZONTAL
        else:
            orientation = wx.VERTICAL
        if self.growCols or self.growRows:
            self.sizer = wx.FlexGridSizer(self.rows, self.cols,
                                          self.vgap, self.hgap)
            for i in self.growCols:
                self.sizer.AddGrowableCol(i)
            for i in self.growRows:
                self.sizer.AddGrowableRow(i)
        elif (self.cols > 1 and self.rows != 1) or \
             (self.rows > 1 and self.cols != 1) or \
             (self.vgap and orientation == wx.VERTICAL) or \
             (self.hgap and orientation == wx.HORIZONTAL):
            self.sizer = wx.GridSizer(self.rows, self.cols,
                                      self.vgap, self.hgap)
        else:
            self.sizer = wx.BoxSizer(orientation)
        if not self.text is None:
            sbox = wx.StaticBox(self.view, -1, self.text)
            self.holder = wx.StaticBoxSizer(sbox, orientation)
            self.holder.Add(self.sizer, **self.sizing)
        else:
            self.holder = self.sizer
        if self.view is None:
            self.view = self._parent.view
            self.assemble(*self._args, **self._kwds)
        else:
            self.view.SetSizer(self.holder)
            self.assemble(*self._args, **self._kwds)
            self.holder.SetSizeHints(self.view)

Donnal Walter
Arkansas Children's Hospital

···

--- Donnal Walter <donnalcwalter@yahoo.com> wrote:

In automating the use of sizers, my preliminary experiments
seem to indicate that the differences in relative efficiency
of these sizers is negligible, but I wonder if I am missing
something. If not, I am tempted just to build multiply nested
wx.FlexGridSizers regardless of whether or not all features
are needed in every case.

Donnal Walter wrote:

One might presume that a wx.GridSizer with one column would be
somewhat less efficient (by some metric, speed or memory use or
both) than a wx.BoxSizer in vertical orientation. One might also
presume that a wx.FlexGridSizer with no growable columns or rows
would be somewhat less efficient than an equivalent wx.GridSizer.
Are these presumptions true,

Probably.

and if so, are the differences in
efficiency of any real significance,

Doubtful. There is probably more time in calculating the minsize of all the items in the sizer (something that all sizers do) than in doing the sizer-specific layout/size calculations.

especially if one intends to
use multiply nested sizers?

Every level of nesting adds a level of recursion in the above calcs, but again the sizer-specific parts will be the smaller parts of the whole.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!