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
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
