On Sunday, October 30, 2011 09:43:43 pm Paul McNett wrote: > On 10/30/11 8:35 AM, John Fabiani wrote: > > Good thing I read both of your replies because at first it made no > > sense.;-) > > And neither of you two seem to understand the point of my changes. It isn't > about flicker, and it isn't about wanting to delay the child requeries. It > is simply about optimizing - in the UI - the quick navigation of records. > > The user is viewing order 1131, and wants to take a look at 1141. So they > click 10 times on the 'next' arrow in the toolbar. Delaying the update() - > which it sounds like we all agree is pretty expensive - to the point in > time where the user has landed on the record they are actually interested > in, was the idea. > > Now, I also added code to tell the parent bizobj not to requery the > children during the row navigation, to keep the bizobj from starting a > domino-effect requery chain down the line during this quick navigation, > because I don't think it makes sense to requery children we aren't > actually interested in, especially when doing so would make the UI that > much less responsive during this quick navigation. > > Incidentally, I am noticing less flicker with these changes, I think > because delayed updates() are no longer stacking up on top of each other. > > Paul
First the sentence you quoted was directed at Jacek (he used True and Not False for one of the properties in his example code). I believe I understood your point for making the changes - you explained it well. And I too have seen the delay of to many updates. That said, I also say that my clients are not complaining about the performance of the current forms. And beyond that, I said that the retrieval of data was not the issue. In my case your 10 clicks would have caused a retrieval delay of around 3000 MS (3 seconds) - so adding the delay to the retrieval does not make any sense to me. Which is was one of Jacek's points (he provided his timings). I don't recall when, but I believe Ed added some code to deal with the stacking of calls to update - that helped the performance of my UI (fixed most of the flicker too I think). I tested your code changes and I did not see any problems (after you made all the required commits) nor did I see a performance increase in the UI. Ok so I saw no difference. What does that mean! It could be that my data needs are not the problem (like I said). Maybe the code you added did little to reflect on what is slowing the UI on my forms. But you said you saw "much better performance" - I did not see an increase in the UI performance. What I do know is the area that takes the longest is wxPython->core ->notify() on Linux and suspect notify() is the issue on windows too. Johnf _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-dev Searchable Archives: http://leafe.com/archives/search/dabo-dev This message: http://leafe.com/archives/byMID/[email protected]
