Jeffrey Harris wrote:
The usual solution for avoiding blocking the UI is to do any CPU-intensive work on a background thread. I'm sure this is obvious to many people but I just want to be explicit: The wx UI only has one thread, and that is currently where we do most of the work. The UI thread has its on view into the chandler repository, and so changes to that view almost always occur on the UI thread.Hi Folks, The big usability issue I'd like to solve in 0.7 is having the UI freeze. I'd like to find some clever way to minimize, or preferably do away with, UI freezing (most notable at commit time). It drives me crazy when I'm using the app. Is this a vain hope? In general, I think we can do this: for major data updates in a view like import, we just spin up (or grab an unused) background thread/view and use that. It might be time to start thinking about a thread/view pooling mechanism so that we can cheaply "spin off" work to worker threads. However, I think that it is going to be hard to avoid a freeze of the UI thread during a commit() on that view for that thread..mainly because the usual solution of doing that on a separate thread wouldn't work - even if you spun up a separate thread for commit() on the UI view, the UI could make changes to that view during the commit().. But I don't know about refresh() - Andi, is refresh() a time-consuming operation if lots of data is coming in from other views? Or if the incoming data doesn't conflict with the current view, maybe this is a cheap operation? The only thing I can think of is to somehow make views block on any new changes when a commit() or refresh() is in progress on that view... that way you could actually spin off the commit() to a new thread, but the UI wouldn't block until someone actually tried to make changes to the thread. But then you end up using locks & other annoyances that we're trying to avoid anyway. Seems less than ideal. I think we can be even more effective if we just be careful about the way we write certain code. A few patterns/thoughts: 1) we should think about the way we're blindly using self.itsView all the time - I think there are times when we make changes from a Block, in the UI thread, using self.itsView, when changes to those items aren't really necessary to see immediately. Perhaps if there was an easy mechanism to specify "this change doesn't need to happen on the UI thread" and instead of using self.itsView and the current thread, we could use some background view and thread instead. 2) we should commit() fairly often on the UI thread - how terrible would it be to have a snappy UI for five minutes and then have it slow to a crawl while all the changes accumulated in those 5 minutes were committed? Instead we should be using the CPU time between user actions to commit what we can. Perhaps what we need is commit-on-idle or something? Alec Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
