[Dev] wxSynchronizeWidget hints
John Anderson
john at osafoundation.org
Fri Oct 21 10:55:57 PDT 2005
Blocks and widgets doen't really have a controller. But I don't really
care about that. If you want to make a controller we can do that.
What I really care about is a performance issue. I want to be able to
process the notifications for my table, ignore changes to items that
aren't visible and ONLY keep a dirty bit if the change affects something
on the screen. I don't want to accumulate your hints on my block because
I'll never use them. It just makes things way more efficient if we can
process notificaitons as we go instead of storing them to process later.
Surely we can think of a way to do this that works with your MVC view of
CPIA, right?
John
Alec Flett wrote:
> John Anderson wrote:
>
>> I'd still vote for this hint accumulation to be block specific, e.g.
>> Calendar only. Consider the case where you did some very large
>> operation and didn't get back to the idle loop for a long time. Also,
>> for many blocks, e.g. Table and Calendar most if not all the hint
>> information doesn't need to be kept around until synchronization, it
>> can be processed when the event is handled and never needs to be stored.
>
> I think that doing that would once again break the MVC paradigm in
> CPIA. It seems like you're saying that for some operations, the model
> should be talking directly to the view, and bypass the controller..
> the notification mechanism is a pretty key part of the controller. The
> controller (in this case the block synchronizing code) needs to ensure
> that mutations to the model are propagated to the view in the order
> they happen. If the model (blocks) immediately updates the view
> (widgets) in some cases, but notifications are also coming in
> asynchronously via the synchronizeWidget() call, then things are more
> or less guaranteed to get out of sync.
>
> Plus I'm not really sure why accumulating a list of hints is harmful.
>
> Maybe you're worried about memory usage? The hints are tuples of
> things like (collection, operation, item) and maybe 1-2 other
> parameters. We're talking about 16-32 bytes per hint - only 16k even
> if tons of events come in. They don't take up a lot of memory, and
> python lists are very efficient.
>
> Maybe you're worried that if 10,000 hints are passed in via
> wxSynchronizeWidget() that the widget in question would waste a lot of
> time processing 10,000 hints? I feel like that is an optimization we
> can make on a per-widget level - if 10,000 hints come in, then we just
> blow away the widget and rebuild it from the block data. But we make
> that call when we hit performance limits - we don't prematurely
> optimize that now.
>
> Alec
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>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/20051021/c75047ae/attachment.htm
More information about the Dev
mailing list