On 03/09/2010 12:07 AM, rgheck wrote:
The attached patch attempts to address the underlying cause of bug
6522. My other fixes all have problems, which trace to the fact that
we are calling updateBuffer()---what used to be called
updateLabels()---before we are really ready to do so. The patch also
does something we've been wanting to do for a while anyway, namely,
bring some sense to the whole updateLabels() nightmare.
The patch introduces an argument to DispatchResult that tracks whether
we need to update the Buffer. This reduces the number of updateBuffer
calls to six or seven from a whole lot more than that, and some of
these can still go, too. Ideally, we'd like one such call, at the end
of the dispatch() process, but that doesn't seem entirely likely.
I don't think this will introduce instability, as delaying the call to
updateBuffer() shouldn't have ill effects. I'll guess, though, that
there are some missing updates in here, but these can easily enough be
fixed. In any event, it is essential. What caused 6522 will cause
other problems.
Please, please have a look at this. I'd particularly appreciate it if
people could look at the things marked "FIXME audit updateBuffer
calls". These are the ones that can still go, or that I'm not sure can
go.
This is a very good and welcome initiative.
First comment: You call cur.needBufferUpdate() but that does nothing ;-)
I suggest to have two different method for setting/getting:
+ ///
+ void setNeedBufferUpdate(bool u);
+ ///
+ bool needBufferUpdate() const;
Abdel.
