Hi Alec:
If we use commit points for undo points, then it typically makes sense to commit after finishing an undoable operation or commit the last operation before starting an undoable operation in the UI thread. I think DeleteSelection is an undoable operation, so I think the commit is appropriate -- not the refresh.
I suspect the reason the commit might be so slow isn't because of the items that were deleted by DeleteSelection, but instead, all the other items that were changed in other threads or as part of startup. So I think when we're done with startup we should do a refresh in the UI thread and when other threads have items for us they should notify the UI thread to do a refresh. This would solve the performance problem if it isn't the items deleted and make undo possible for not much effort. However, it's slow because committing the items changed by DeleteSelection is slow, then the solution isn't to avoid commit, the solution is to speed up commit.
If this is confusing I'd be happy to go over it on a white board when we're both at OSAF
John
Alec Flett wrote:
Hey John - I've got a fix for two bugs in one patch: http://bugzilla.osafoundation.org/attachment.cgi?id=494&action=edit
The two bugs are: http://bugzilla.osafoundation.org/show_bug.cgi?id=2322 about switching from commit() to refresh() to gain some performance
http://bugzilla.osafoundation.org/show_bug.cgi?id=2090 about fixing up the column widths when the grid widget is sychronized
Do you mind taking a look? I can explain any of it too but its pretty small & straight forward...
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
