[Dev] Blocking UI in 0.7

[John Anderson]

Alec Flett wrote:

> Jeffrey Harris wrote:
>
>>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?
>>
>>  
>>
> 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.

>
>
> 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
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/dev/attachments/20060103/8f22bbf6/attachment.html