lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Not urgent: a plausible micro-optimization


From: Vadim Zeitlin
Subject: Re: [lmi] Not urgent: a plausible micro-optimization
Date: Sat, 17 Feb 2018 17:56:42 +0100

On Fri, 16 Feb 2018 00:49:53 +0000 Greg Chicares <address@hidden> wrote:

GC> We have a
GC>     wxDocMDIParentFrame*  frame_;
GC> in
GC>     Skeleton::UpdateViews()
GC> where we do this:
GC> 
GC>     for(auto const& i : frame_->GetChildren())
GC>         {Do Something Cool That Takes A Bit Of Time}
GC> 
GC> Does wx provide something like GetChildren() that's
GC> designed to put the currently-focused child (if any)
GC> first in the list?

 No, but it's easy to do the equivalent in lmi code.

GC> I think that could improve an
GC> application's perceived responsiveness, by updating
GC> the "current" child first in a loop like this one.
GC> 
GC> Or is this trivial to do in lmi, e.g., by sorting
GC> the result of GetChildren() to bring any focused
GC> element to the front?

 IMHO it doesn't really make sense to do a full sort without being able to
compare windows in Z-order (which we can't easily do currently), but it's
pretty simple to just do the update for the active child first and then for
all the other ones later, please see the changes in

        https://github.com/vadz/lmi/pull/68

which do exactly this.

 I've tested this with a simulated 2s delay inserted in the code and
toggling "Use default supplemental columns" on/off in the preferences
dialog and this change does result in the current window being updated
noticeably faster -- but please note that the call to Update() is needed
for this to happen, otherwise the changes wouldn't become visible
immediately, even if we make them in the right order.

 Regards,
VZ


reply via email to

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