lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] wx-2.9.5-rc1 regression with conditional controls enablement


From: Greg Chicares
Subject: Re: [lmi] wx-2.9.5-rc1 regression with conditional controls enablement
Date: Mon, 22 Jul 2013 15:18:26 +0000
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

On 2013-07-17 19:13Z, Vadim Zeitlin wrote:
> On Wed, 17 Jul 2013 00:42:46 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> >  Ideal would be to replace a flat vector by a map of parent pages to the
> GC> > (interesting) controls inside them, then we could iterate over this 
> instead
> GC> > of iterating over GetChildren().
> GC> 
> GC> At first I thought you were suggesting that iteration would be faster 
> over a
> GC> std::map than over a std::vector. Rereading this more carefully, though, I
> GC> see the real point: sometimes we want to iterate over the current page 
> only,
> GC> and sometimes over all pages; but controls aren't added or removed, so we
> GC> only need to generate a container of controls once
> 
>  Yes, exactly.

I measured this. Calling Lineage() on the MvcController (which is the
wxDialog) takes about twenty microseconds, which rounds to zero
milliseconds. Calling Lineage() on a notebook page takes less time.
Optimizing this shouldn't make a noticeable difference.

As you point out, the dialog is slow to appear, and I'd welcome any
further suggestions for speeding it up. ConditionallyEnableItems()
may be what takes the most time; at least that was my impression
in the past.

>  If we can assume that the dependencies are simple, i.e. each control whose
> state needs to be changed dynamically depends on the value of only a single
> other control (be it a checkbox, radiobox or something else), then I think
[...snip ideas for that case...]

The dependencies are quite complex: Input::DoHarmonize(), which
expresses them, is seven hundred lines long.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]