Re: About Creating New Packages/Widgets & Other Dev Help

> On Dec 26, 2015, at 4:33 AM, Metallicow <[email protected]> wrote:
> 
> 
> 
> On Thursday, December 24, 2015 at 10:07:10 AM UTC-6, kevino wrote:
> 
> 
> When moving around inconsequential calls like event.Skip() makes a difference in app behavior, it usually indicates that there is a performance problem somewhere else in the app. Generally speaking, having lots of recursion and events firing makes things hard to debug and should be avoided if possible. I can't say much else without seeing the code, but if you've only been testing this on one machine, I'd recommend testing on other machines with significantly different specs, if you have one available, and see if your results match. That will help give you an idea of if your fix is a general purpose fix or just appears to fix the problem on a particular test machine.
> 
> Regards,
> 
> Kevin
> 
> 
> Re: ShapedBitmapButton loopage of events... 
> I have tested quite a bit on windows and it does work on a couple versions of linux kubuntu and mageia. Not actually tested yet on a mac...
> The basic concept of the madness at play here is that all classes in the family tree might/will get the event at least once. This probably sounds
> like quite a bit of overkill but it is needed when the buttons(rects) are "overlayed" in any such way for the alpha drawing to work and also for 
> animations of the buttons to display correctly. This advanced behaviour is only needed if they are overlayed, otherwise a simple sizer keeps them from fighting and the crazy looping is not needed. There needs to be built a draw list, quadrant list, order list and a giveup(the event"Skip", so the end built bitmap is draw right on top) window for every event processed.

Are you using a series of controls with sizers to do the layout for a custom-drawn button? 

Regards,

Kevin

> So what is happening is that the same method(s) recurse within the same class over and over passing the event to its siblings/parents/etc/etc instances
> until the top is reached or drawing has stopped because another accepts the responsibility of really processing the event. It is essentially conditional logic
> when it comes down to when or if Skip is called, because the original widget that fired the event may not be the one who is going to say Skip, if at all.
> Local opts and killing all the dots has helped quite a bit with performance. But there is a bit of lag when about 100 or more get into the same room or with a moving
> WrapSizer.
> Or in other words, I am recreating the same event for the sibling and parent widgets every check, while still maintaining an passing the "event" "loop", but sorta actually ate it.
> Maybe that makes better sense. Like playing hot potato until somewidget drops it. 
> I'm not quite sure exactly how to explain it or document it. I just know I've spent a huge amount of time line by line trying to perfect it. and as a basic widget 
> it works superbly already. Just some of the more advanced techniques when applied still need smoothing out... like the overlaying and smooth move animations.
> -- 
> You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]>.
> For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups "wxPython-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.