[Dev] Blocking UI in 0.7
john at osafoundation.org
Tue Jan 3 10:29:31 PST 2006
Alec Flett wrote:
> Jeffrey Harris wrote:
>>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?
> 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.
> 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?
I was hoping, someday, to have the commit point be the unit of undo,
e.g. if you did a delete, you'd commit after the operation. Of course
this requires the ability to roll back changes to previous commit
points, which doesn't yet exist.
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>Open Source Applications Foundation "Dev" mailing list
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>Open Source Applications Foundation "Dev" mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dev